How should teams connect IT service management with identity governance?

Why This Matters for Security Teams

Connecting IT service management with identity governance is not a workflow polish exercise. It is the point where access intent, approval evidence, and revocation discipline either stay synchronized or drift apart. When service requests and identity decisions live in separate systems, teams create speed in the front door and risk at the back door. That gap shows up in stalled deprovisioning, orphaned access, and access that no one can explain during audit.

Current guidance suggests this should be treated as a single control plane for the identity lifecycle, not two adjacent processes. NIST’s Cybersecurity Framework 2.0 emphasizes governance and continuous improvement, while NHIMG research shows that only 20% of organisations have formal offboarding and API key revocation processes in place. That matters because service desks often optimize ticket closure while identity teams optimize policy compliance, and the handoff between them becomes the weakest control. The result is a process that looks efficient on paper but leaves access lingering in production systems.

In practice, many security teams discover the problem after a joiner-mover-leaver event has already left stale entitlements behind, rather than through intentional lifecycle design.

How It Works in Practice

The operational model should start with a shared request-to-revoke lifecycle. IT service management owns the request intake, service catalog, approvals, and fulfillment status. Identity governance owns access policy, access review, segregation of duties, and recertification. The two systems need to exchange authoritative data so that one ticket, one approval chain, and one access decision can be traced end to end.

That usually means integrating the service desk with identity governance for automated provisioning and deprovisioning, then tying approvals to role, group, or entitlement policy rather than ad hoc email sign-off. For human users, that may mean joining a standard role assignment to a service request. For NHIs, the same lifecycle thinking applies to service accounts, API keys, tokens, and certificates, with the added requirement that revocation and rotation happen automatically. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is exactly why ITSM and identity governance must share inventory and ownership data.

A practical integration usually includes:

• Service desk tickets that trigger policy-based access workflows instead of manual fulfillment.
• Identity governance rules that validate entitlement requests against role, location, manager, and risk context.
• Automated provisioning and removal tied to employment status, project end dates, and access recertification outcomes.
• Reconciliation jobs that detect orphaned accounts, expired approvals, and access that no longer maps to a current ticket.

For measurable control, teams should track approval latency, time to revoke, percentage of automated removals, and exceptions requiring manual intervention. The operational goal is not just faster ticket handling, but provable access change hygiene across the full lifecycle. This aligns with identity governance practice and with the lifecycle emphasis in NHIMG’s Lifecycle Processes for Managing NHIs.

These controls tend to break down when service catalog items are poorly defined and entitlement ownership is unclear, because automation cannot compensate for ambiguous approval authority.

Common Variations and Edge Cases

Tighter integration often increases process overhead at first, requiring organisations to balance speed against policy accuracy and auditability. That tradeoff is real, especially when legacy systems, shared accounts, or outsourced operations still depend on manual steps.

Best practice is evolving for cases where ITSM and identity governance do not map cleanly. For example, a single service request may cover multiple systems with different approvers, while an access review may uncover entitlements that no current ticket can justify. In those cases, the governance system should become the source of truth for access status, while ITSM records the operational event and remediation action. There is no universal standard for this yet, but the direction is clear: teams need closed-loop revocation, not ticket closure as a proxy for control.

Two edge cases deserve special attention. First, emergency access or break-glass scenarios should be pre-approved in policy and logged back into both platforms after use. Second, NHI credentials often outlive the service request that created them, so teams need separate controls for credential rotation and ownership review. NHIMG’s Top 10 NHI Issues is a useful reminder that over-privilege and weak rotation are recurring failure modes, not one-off exceptions. Where third-party integrations or federated workflows are involved, the gap is usually in accountability rather than tooling.

Related resources from NHI Mgmt Group

• How should identity teams connect incident management with access governance?
• How should security teams connect asset discovery to identity governance?
• How should security teams connect hardware asset management to IAM governance?
• How should teams build an IT asset management programme that supports identity governance?