Who should own access decisions when service management and IAM are connected?

Why This Matters for Security Teams

When service management and IAM are connected, the ownership question is really about control boundaries. If the service desk can approve access end to end, it becomes the operational bottleneck and the de facto policy engine. That creates audit ambiguity, weak segregation of duties, and inconsistent decisions that are hard to defend later. The identity function should own the rule set, approval criteria, and entitlement model, while service management should handle intake, routing, evidence collection, and case tracking.

This distinction matters even more for non-human access because service accounts, API keys, and workload identities are often over-privileged and under-reviewed. NHIMG notes that 97% of NHIs carry excessive privileges and only 20% of organisations have formal offboarding and revocation processes, which makes delegated control without clear ownership especially risky. For a practical reference on lifecycle governance, see the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the OWASP Non-Human Identity Top 10.

In practice, many security teams discover too late that the help desk has been approving exceptions and access changes informally after a review failure, rather than through an intentional governance model.

How It Works in Practice

The clean operating model separates decision authority from workflow execution. The identity team, IAM engineering function, or delegated policy owner defines who can approve what, under which conditions, and with what evidence. Service management then acts as the intake and orchestration layer: it validates request completeness, attaches tickets, routes approvals, and records the outcome. That means the service desk can move quickly without becoming the authority that interprets policy.

For human access, this usually maps well to RBAC and standard approval chains. For NHI access, the pattern should be stricter because the request often grants machine-to-machine reach, long-lived tokens, or elevated runtime permissions. Current guidance suggests combining policy-as-code with case management so the approval decision is evaluated against context such as workload type, environment, data sensitivity, and expiry window. NIST’s Cybersecurity Framework 2.0 supports governance and access control discipline, while NHIMG’s Top 10 NHI Issues highlights how quickly access sprawl appears when ownership is unclear.

• Service management owns request intake, evidence, notifications, and SLA tracking.
• IAM or delegated policy owners own approval logic, entitlement design, and exception criteria.
• Access decisions should be time-bound, logged, and reviewable by the control owner.
• High-risk requests should require step-up review or a separate approval path, not a help desk override.

This model works best when the approval policy is explicit, reviewed regularly, and tied to the system of record. These controls tend to break down in fast-moving environments where teams route urgent changes through chat, because the ticketing tool no longer reflects the real decision path.

Common Variations and Edge Cases

Tighter separation between service management and IAM often increases process overhead, so organisations must balance control assurance against response speed. That tradeoff becomes visible in support-heavy environments, during incident response, or when access requests are frequent and low-risk. The right answer is not always a rigid approval chain; current guidance suggests tiering decisions by risk and delegating only pre-approved, low-impact actions.

One common edge case is delegated administration. A business unit may be allowed to approve access within a bounded domain, but the identity team should still define the policy, validate the delegation, and retain oversight. Another is emergency access, where service management may trigger the workflow but should not authorise the change itself. For background on lifecycle control and audit expectations, see Ultimate Guide to NHIs — Regulatory and Audit Perspectives and Ultimate Guide to NHIs.

The main exception is when a platform team operates as both service owner and policy owner for a tightly scoped system. Even then, the same separation should exist inside the team between request handling and entitlement governance. If that line disappears, access approval becomes an operational convenience instead of a controlled security decision.

Related resources from NHI Mgmt Group

• Who should own OAuth app and service account cleanup?
• How do IAM teams know if privileged access controls are actually working?
• Why do SSO tools often fail to solve access governance on their own?
• How should security teams run access reviews for non-human identities?