What is the difference between identity governance and ITSM for access control?

Identity governance defines who should have access, under what conditions, and how it is reviewed. ITSM manages the operational workflow used to request, approve, and track that access. When they are integrated, teams reduce tool switching, but the governance rules still need to be stronger than the ticketing process.

Why This Matters for Security Teams

Identity governance and ITSM often get lumped together because both touch access approvals, but they answer different questions. Governance decides whether access is appropriate in the first place, while ITSM records and routes the operational work. That distinction matters most for NHIs, where service accounts, API keys, and automation often outnumber people and are harder to review manually. NHI Mgmt Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises in the Ultimate Guide to NHIs, so ticketing alone cannot substitute for lifecycle control. Current guidance also aligns with NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10, both of which emphasise access governance as a security function, not just a service desk workflow.

The practical risk is that ITSM can prove a request was processed while governance still fails to prove the entitlement was justified, least-privileged, or removed on time. In practice, many security teams encounter privilege creep only after a ticketing trail looks complete but a dormant account is already over-privileged.

How It Works in Practice

A useful operating model is to treat identity governance as the policy layer and ITSM as the execution layer. Governance defines who may receive access, under what conditions, with what review cadence, and whether JIT or RBAC is appropriate for the workload. ITSM then handles the request, approval routing, assignment, and audit trail. For NHIs, that means the approval should be driven by workload purpose, data sensitivity, environment, and expiration, not by a generic human-style role. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful for mapping those lifecycle checkpoints, while Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows why review evidence must be stronger than ticket closure alone.

• Use governance to define entitlement policy, separation of duties, and review frequency.
• Use ITSM to collect the request, approvals, evidence, and change history.
• Feed ITSM approvals into identity governance so access recertification can test what was granted against policy.
• For secrets and service accounts, require ownership, expiration, and revocation triggers rather than open-ended tickets.

Practitioners should also align the control model with external guidance such as the PCI DSS v4.0 expectation for controlled access and the auditability expectations reflected in NIST Cybersecurity Framework 2.0. Where teams see excess privilege in the wild, the issue is rarely the absence of a ticket. It is usually that the ticketing process was never designed to enforce policy at the identity layer, especially in environments with short-lived automation, multiple approvers, or delegated admin paths that bypass governance.

Common Variations and Edge Cases

Tighter governance often increases approval overhead, so organisations have to balance control strength against operational speed. That tradeoff becomes sharper when access is requested for low-latency automation, ephemeral pipelines, or production support accounts that cannot wait for manual review. Current guidance suggests that ITSM can automate the workflow, but it should not be the source of truth for entitlement decisions; that role belongs to identity governance, PAM, and increasingly policy-as-code. For NHI-heavy environments, the Ultimate Guide to NHIs — Key Challenges and Risks is a stronger reference point than generic help-desk process design, and the Top 10 NHI Issues highlights why visibility and rotation failures often sit outside classic ITSM controls.

There is no universal standard for this yet, especially where agentic tools, temporary vendors, or cross-cloud service accounts are involved. In those cases, organisations should prefer short-lived access, explicit expirations, and independent recertification over “approved once, reused forever” tickets. The exception is highly regulated environments where ITSM evidence may be necessary for change control, but even there the governance decision still needs to remain separate from the operational record. Ultimate Guide to NHIs — Standards is a practical way to align those controls without conflating them.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between human IAM controls and NHI governance?