Should organisations use ITSM or IGA for access governance?

How ITSM and IGA split the access governance job

ITSM is the workflow and service record layer. It captures the request, approvals, ticket history, SLA, and evidence trail so the organisation can show who asked for access, who approved it, and when it changed. IGA is the control layer for the entitlement itself: who should have it, whether it is appropriate, and whether it should continue.

That split matters because access governance is not just about processing requests. It is also about entitlement design, role logic, segregation of duties, and lifecycle control. A request can be perfectly routed in ITSM and still create the wrong access decision if IGA does not evaluate the entitlement against policy, role, and business need. For a practical overview of that split, see IAM and IGA Basics.

In other words, ITSM answers “was this handled properly?” while IGA answers “should this access exist at all?”

What each system should own in the access lifecycle

Use ITSM when the work is service management: intake, assignment, approval routing, status tracking, exception logging, and communication back to the requester. Use IGA when the work is identity governance: entitlement catalogs, role mappings, access certification, joiner-mover-leaver logic, recertification, and revocation decisions.

This division is strongest when the entitlement has a lifecycle longer than the ticket. An access request is only the beginning. The real governance question is whether the access should expire, be recertified, be reduced to a narrower role, or be removed entirely after the business need ends. That is why lifecycle discipline is central to NHI Lifecycle Management Guide and to the broader IGA model.

Where organisations go wrong is treating the ticket as the control. The ticket records a decision; it does not prove the decision remains valid over time. IGA fills that gap by continuously checking entitlement state against policy and ownership.

Why the distinction improves governance, not just administration

ITSM is optimized for process completion, but governance needs policy enforcement. If access is granted only because a ticket was approved, the organisation can accumulate role creep, stale access, and inconsistent approvals across teams. IGA reduces that drift by applying consistent rules for entitlement birth, change, review, and removal.

That is why access governance should be designed around the entitlement, not the request. A mature programme uses ITSM as the front door and audit trail, then uses IGA to decide whether the access is permitted, proportional, and still needed. For organisations building that capability, Access Reviews and Certification Guide is the more relevant control lens for periodic validation, while IGA Buyer's Guide helps when selecting tooling that must support requests, reviews, roles, and connectors.

Practically, ITSM should preserve the business narrative and operational trace. IGA should preserve the security decision and the entitlement state. If those responsibilities blur, reviews become paperwork and approvals become rubber stamps.

Risk and Threat Considerations

Using only ITSM for access governance creates a common failure mode: access can be approved once and then left in place long after the original need has disappeared. That increases the chance of excessive privilege, orphaned access, and weak revocation discipline, especially in environments with shared roles or non-human accounts. A good governance design has to account for that drift.

Failure mechanism: The ticketing process records the request and approval, but no control continuously checks whether the entitlement is still justified, correctly scoped, or due for removal. Over time, that leaves residual access that attackers or insiders can abuse.

Impact: Organisations can end up with persistent over-privilege, audit findings, and larger blast radius when an account or credential is misused. For governance controls that directly address this problem, Role Mining and Role Design Guide and Segregation of Duties (SoD) Guide are useful because they focus on entitlement structure and conflict detection, not just request handling.

Practitioner Guidance

What to prioritise: Decide which system is authoritative for the entitlement decision before you connect them. ITSM can approve and document a request, but IGA should remain the source of truth for entitlement scope, expiry, and removal.

What to verify: Confirm that every access path has an owner, a review cadence, and a revocation trigger. If the process cannot tell you when access must end, the governance design is incomplete.

Common mistake: Do not build a workflow that ends at “ticket closed.” A closed ticket is not evidence that access is still appropriate, only that a process step finished.

Practitioner takeaway: The cleanest operating model is ITSM for request orchestration and evidence, with IGA for entitlement control and lifecycle enforcement; if one tool is doing both jobs, check whether governance has been reduced to administration.

Related resources from NHI Mgmt Group

• How should organisations use higher IGA budgets to reduce manual access governance work?
• What is the difference between role-based access and API key governance for NHI security?
• How should security teams use IAST and RASP in NHI governance?
• Should organisations prioritise external exposure or internal credential governance first?