ITSM tools and access governance: why ticketing is not enough

At a glance

What this is: This is a Zluri analysis of why ITSM tools are not enough for access requests and why governance requires policy-driven entitlement decisions.

Why it matters: IAM teams need to separate request routing from access governance so they can control scope, duration, and segregation-of-duties risk across human and non-human access flows.

Context

ITSM systems are built to route work, not to govern who should get which permissions, for how long, or at what level. That distinction matters in identity programmes because the control problem is not request intake, it is entitlement decisioning.

In access workflows, a ticket can record approval but still leave scope, duration, and role fit unresolved. When ITSM is treated as the governance layer, organisations typically inherit over-permissioned access, audit friction, and revocation gaps.

This article uses access requests as the lens, but the underlying issue is broader identity governance across human access and adjacent non-human access patterns where approvals alone do not establish least privilege.

Key questions

Q: What breaks when ITSM handles access requests without a governance layer?

A: The request may be approved and closed, but the organisation still has no assurance that the access is properly scoped, time-limited, or compatible with segregation-of-duties rules. ITSM can move work efficiently, yet it does not evaluate entitlement appropriateness. That is why ticket closure can coexist with over-permissioning and audit gaps.

Q: Why do access requests in ITSM create over-permissioning risk?

A: Because a ticket workflow treats each request as a separate event, while real identity risk accumulates across many requests and systems. Users can gain overlapping permissions, broader license tiers, or persistent access that no single ticket looks dangerous on its own. The risk emerges from cumulative entitlement drift, not from one approval alone.

Q: How can teams tell whether access governance is actually working?

A: Look for short revocation times, low rates of stale entitlements, and repeatable access review outcomes across systems. If accounts remain active after role changes or offboarding, governance is not effective. Good measurement focuses on whether access is removed when it stops being justified.

Q: What should IAM teams do with ITSM after adding access governance?

A: Keep ITSM for service requests, incidents, and change workflows, but stop using it as the system that decides entitlement scope. IAM teams should route access through a policy engine, preserve the audit trail, and reserve manual review for high-risk or exception cases.

Technical breakdown

Why ticket routing is not entitlement governance

ITSM tools are designed to log, route, and close work items. Access governance is different because it must decide what access is appropriate before the request is fulfilled, not merely record that someone approved it afterward. That requires policy logic that can evaluate role, department, application risk, and existing access overlap. A ticket can prove a workflow happened, but it cannot determine least-privilege scope or detect whether the requested access conflicts with current entitlements. In identity terms, the workflow is administrative; the decision is governance.

Practical implication: separate request handling from entitlement policy so approval routing does not become the access decision.

How policy-driven provisioning changes access requests

A policy engine changes the control point from queue management to entitlement evaluation. Instead of granting a generic application request, the system can map the request to a specific license tier, permission set, approval path, and expiration window. That matters because the same application can carry very different risk depending on whether the user receives read-only, standard user, or administrative access. Time-bound access also matters because project-based access should end automatically rather than depend on manual revocation. This is where access governance becomes operational, not just procedural.

Practical implication: define approval rules, license tiers, and expiry conditions before provisioning starts.

Where SoD and over-permissioning emerge in ITSM-only workflows

When ITSM is the only control layer, the system tends to approve requests as isolated events. That creates blind spots for segregation-of-duties conflicts, standing access overlap, and license inflation. A person can accumulate multiple roles or tool permissions across successive tickets without any one request appearing obviously risky. Over time, the environment drifts away from intended access boundaries, and audit teams are left reconstructing intent from ticket history. The failure is not speed or usability. The failure is that ticketing has no native model for cumulative identity risk.

Practical implication: review accumulated access across requests, not just the outcome of each individual ticket.

NHI Mgmt Group analysis

Ticketing is not an identity control plane: ITSM can record access demand, but it cannot establish whether the access should exist, at what scope, or for how long. That is why ticket closure and governance completion are not the same event. For practitioners, the relevant distinction is between operational workflow and entitlement authority.

Scope, duration, and SoD are separate governance decisions: Access requests often bundle these decisions together as if a manager approval can cover all three. It cannot. Scope defines what the user gets, duration defines how long it stays live, and segregation-of-duties defines whether the combination is acceptable at all. Treating them as one decision is how over-permissioning enters the estate.

Policy-driven access is the named concept here: The article points to a control model where access decisions are evaluated against rules before provisioning, rather than after a ticket is approved. That pattern is what prevents the request queue from becoming the de facto governance layer. Practitioners should recognise this as entitlement intelligence, not ticket automation.

Real-time access posture beats retrospective audit cleanup: A ticket log is evidence, not governance. If an organisation can only tell who has access after audit prep begins, it is already operating with stale entitlements and weak revocation discipline. The field should move from documenting access events to continuously governing entitlement state.

ITSM and IAM play different roles in the same operating model: ITSM remains useful for incident, change, and service request handling, but access governance needs a dedicated decision layer. The more access requests look like ordinary tickets, the more likely it is that privilege creep will be normalised. Practitioners should design for separation of duties between workflow and entitlement authority.

From our research library:

• Gartner predicts that AI systems will initiate 50% of all service requests by 2030, driven largely by agentic AI.

What this signals

The real programme shift is to treat access requests as entitlement decisions, not service desk work items. Once that separation is clear, organisations can enforce scope, duration, and approval rules without turning every request into manual queue management.

Policy-driven access creates a better operating model for IAM because it moves governance to the point of issuance. That reduces the chance that orphaned permissions, overlapping entitlements, and delayed revocation become normal outcomes of routine ITSM processing.

For practitioners

• Separate request intake from entitlement approval Keep ITSM as the request front door, but move access-scoping decisions into policy logic that can evaluate role, application risk, and existing access before provisioning.
• Define license tier and permission-level rules Map each requested application to the exact entitlement variant a user can receive, including read-only, standard, and admin access, so approvals do not default to broad access.
• Build automatic expiry into project access Set access to revoke itself when the approved business window ends, instead of relying on manual cleanup after a ticket has closed.
• Review cumulative access for SoD conflicts Check whether a user already holds overlapping entitlements across tools before approving a new request, because isolated tickets can hide cumulative privilege risk.

Key takeaways

• ITSM can route access requests, but it does not determine whether the resulting access is least-privilege, time-bound, or SoD-safe.
• The article’s central evidence is operational rather than numerical: ticket workflows can close cleanly while governance failures remain in the entitlement layer.
• Practitioners need a policy layer that evaluates access before provisioning and revokes it automatically when the approved business window ends.

Key terms

• Access Governance: Access governance is the policy and workflow layer that manages how access is requested, approved, certified, and revoked. In SaaS environments it helps standardise control across many applications, reducing inconsistency between teams. It is most effective when it covers both human accounts and non-human identities.
• Entitlement: An entitlement is the permission set that defines what a non-human identity can do after it authenticates. It is usually expressed through roles, policies or access assignments, and unmanaged entitlements are a common reason machine identities become over-privileged over time.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Time-Bound Access: Time-bound access is a control pattern that grants permissions for a defined window and removes them automatically when the window ends. It is a practical least-privilege mechanism for cloud operations and NHI governance because it reduces how long elevated access can be abused.

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 building or maturing an IAM programme, it is worth exploring.