How do ITSM access workflows differ from formal IAM processes?

How ITSM access workflows differ from formal IAM processes

ITSM access workflows are designed to move a request through the service queue with traceability and SLA discipline. Formal IAM processes are designed to make and enforce identity decisions, including who may approve access, what entitlement is appropriate, how privilege is granted, and when it must be reviewed or removed. The difference matters because a ticket can document activity without actually governing access.

Request handling versus identity decisioning

An ITSM workflow usually starts with a request, routes it to the right resolver or approver, and closes it when the operational task is complete. That makes it strong for intake, routing, status visibility, and recordkeeping. IAM begins earlier and ends later: it evaluates the identity, the target resource, the entitlement scope, and the lifecycle implications of granting or revoking access.

In practice, this means the ticket system can say what was asked for, while IAM must decide whether it should exist. A formal access process should not rely on the presence of a completed ticket as proof that the access decision was valid, because the control question is about entitlement and authority, not just workflow completion.

That distinction is why mature environments often integrate the two rather than substitute one for the other. ITSM can remain the orchestration layer, while IAM remains the control plane for policy, approval logic, and entitlement state.

Where the control boundary should sit

The cleanest boundary is that ITSM captures demand and IAM governs authorization. ITSM may record business justification, route approvers, and create an audit trail. IAM should decide whether the request aligns with role, policy, SoD constraints, and revocation requirements, and it should retain the evidence needed for future review.

This becomes especially important for sensitive access, because approval is not the same as entitlement governance. A manager can approve a request in ITSM, but IAM still needs to enforce whether that approval is sufficient, whether a second approver is required, and whether the access expires automatically after the work window ends. For access review and recertification, IAM must also know what was granted, not merely what was requested.

For broader identity and access governance, see Identity Security Programme Guide, which frames how access decisions, ownership, and review fit into a governed operating model. Lifecycle Processes for Managing NHIs is also useful where the same boundary must be enforced for service accounts, tokens, and other machine access paths.

Why the distinction matters in real operations

Blurring ITSM and IAM creates false comfort. A workflow can look mature because every access request has a ticket, but the actual identity controls may still be weak if approvals are inconsistent, entitlement scope is too broad, or removal happens outside the control system. The risk is not the ticket; the risk is the gap between administrative routing and enforceable access governance.

That gap matters most when access is time-bound, privileged, or cross-environment. ITSM can help coordinate the request, but only IAM can reliably implement least privilege, time limits, periodic review, and revocation. If the process cannot show who was granted access, under what policy, and for how long, then the organisation has workflow evidence without control evidence.

Service teams should also be careful not to treat manual exception handling as a normal substitute for policy. Repeated override paths, generic approvers, and tickets that bypass entitlement logic usually signal that the process is optimising speed over control quality. For access-heavy environments, the better question is not whether the request moved quickly, but whether the grant was legitimate, bounded, and later reviewable.

Practical IAM process design benefits from the NHI lifecycle perspective in Top 10 NHI Issues and NHI Lifecycle Management Guide, because the same lifecycle discipline that governs human access also applies when access is held by workloads, applications, or automation.

Practitioner Guidance

What to verify: If a team says its ITSM process is its access control, verify whether the system can enforce policy, expiry, recertification, and revocation, or whether it only records a request that someone approved. A logged approval is not enough if the underlying entitlement state is unmanaged.

What good looks like: The ticketing system captures demand and justification, while IAM owns entitlement logic, approval rules, provisioning, and deprovisioning. The best indicator is that the same access grant can be independently traced from request to policy decision to active entitlement to later review.

Common mistake: Treating manager approval in ITSM as equivalent to authorization. That shortcut works operationally until a reviewer asks whether the approver had authority, whether the access was scoped correctly, and whether the entitlement was removed on schedule.

Practitioner takeaway: Use ITSM to coordinate work, but use IAM to govern access. If you cannot point to a policy-backed entitlement decision and a revocation path, you do not yet have formal access governance.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?
• What is the difference between reviewing human access and reviewing NHIs?