Who should own access decisions when ITSM and IAM responsibilities overlap?

Why This Matters for Security Teams

When ITSM and IAM responsibilities overlap, the main risk is not just duplicate work. It is control ambiguity. If one team can request, approve, provision, and revoke access inside the same workflow, entitlement decisions drift toward operational speed instead of policy. That creates weak audit trails, inconsistent exception handling, and access state that no one truly owns. The issue is especially visible in non-human identity governance, where service accounts and automation often move faster than human review cycles, as reflected in the Ultimate Guide to NHIs.

This is why mature models separate policy ownership from workflow execution. Identity teams should define access rules, approval criteria, and revocation standards, while IT operations should execute the ticketing and fulfillment steps. Current guidance suggests that when those boundaries are unclear, access reviews become performative and exceptions become permanent. The OWASP Non-Human Identity Top 10 also reinforces that overprivileged and poorly governed identities are a recurring failure mode, not a corner case. In practice, many security teams discover the ownership problem only after an audit finding, a stale entitlement review, or a production incident has already exposed it.

How It Works in Practice

The cleanest operating model is a RACI-style split, but only if it is enforced in both process and tooling. Identity and access management should own the policy layer: who may receive access, under what conditions, for how long, and who can approve exceptions. ITSM should own the service workflow: intake, routing, task orchestration, evidence capture, and fulfillment status. This division matters because the same person or team should not be able to set policy and silently bypass it through a service desk queue.

A practical implementation usually includes:

• Access request templates that map each entitlement to a policy owner and an approval path.
• Pre-approved standard access for low-risk requests, with escalation for exceptions.
• JIT approval and revocation steps for privileged or time-bound access.
• Audit logs that record both the business reason and the policy basis for each decision.
• Periodic recertification owned by identity governance, not by the help desk.

For NHI-heavy environments, this separation becomes even more important. Service accounts, API keys, and automation tokens often sit outside normal ITSM expectations, so the identity team must define lifecycle rules while IT operations executes controlled provisioning. That aligns with the governance patterns described in the 2024 Non-Human Identity Security Report, where organisations report a major maturity gap in non-human access management. The control objective is simple: ticketing may move the work, but it should never decide the policy. These controls tend to break down when emergency-change culture overrides approval discipline because the exception path becomes the default operating path.

Common Variations and Edge Cases

Tighter separation between ITSM and IAM often increases coordination overhead, so organisations need to balance governance clarity against delivery speed. That tradeoff is real in shared-service environments, especially when one team runs the platform and another owns the control framework. Best practice is evolving, but current guidance suggests that ambiguity should be resolved in favour of explicit policy ownership, even if it slows the first implementation.

Some environments need special handling:

• In small teams, one group may operate both systems, but the approval authority should still be separated from the execution function.
• In federated enterprises, local ITSM teams may handle intake while central IAM defines entitlement policy and exception thresholds.
• For privileged access, PAM and JIT workflows may require additional sign-off, but the final entitlement state still belongs to identity governance.
• For automated workloads, workload identity and short-lived credentials should reduce dependence on human ticket approval for routine access.

The key exception is emergency access. Break-glass procedures can bypass normal workflow, but only if they are time-bound, logged, and reviewed after the fact. The 52 NHI Breaches Analysis shows how quickly hidden access paths become persistent risk when review ownership is weak. In practice, teams that blur ownership usually do not notice the gap until a revoked entitlement is still active, or an exception has quietly become permanent.

Related resources from NHI Mgmt Group

• Who should own access decisions when service management and IAM are connected?
• Who should own SaaS governance when access, licensing, and renewals overlap?
• Who should own cloud identity decisions when security architecture and IAM overlap?
• How do IAM teams know if privileged access controls are actually working?