Who should own access ticket governance across IT and IAM teams?

Why This Matters for Security Teams

Access ticket governance is not just an operational queue problem. It determines who can approve access, which entitlements are considered normal, and how quickly risky access is removed when business need changes. If IT operations owns fulfilment without a separate identity governance owner, the process often drifts toward convenience rather than control. That gap is exactly where over-provisioning, stale access, and incomplete reviews show up.

The governance split matters because the policy decision and the execution step are not the same control. Current guidance in the NIST Cybersecurity Framework 2.0 still points to clear accountability for access decisions, while NHIMG research on the Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows that auditability depends on defined ownership, not just ticket throughput. In practice, many security teams discover the ownership gap only after an access review, entitlement dispute, or audit finding exposes that nobody can explain why approvals were accepted.

How It Works in Practice

The cleanest operating model is to place ownership with identity governance, IAM, or a dedicated access governance function, while IT service management, infrastructure, or application support handles fulfilment. That means one team defines policy and another team executes requests. The governance owner sets approval rules, entitlement catalog standards, evidence requirements, exception handling, and reconciliation cadence. Fulfilment teams then provision, modify, or remove access against those rules.

In practice, the ticket should carry enough context to make the decision auditable:

• who is requesting access and for what business purpose
• which application, role, or entitlement is being requested
• who is approving, and whether the approver is eligible
• what expiry, review, or revalidation date applies
• what evidence is retained for audit and recertification

This is where the OWASP Non-Human Identity Top 10 becomes useful even for human access workflows, because it reinforces the same governance pattern: ownership of secrets, entitlement scope, and review discipline must sit with the control plane, not the execution team. NHIMG’s Top 10 NHI Issues also highlights a recurring failure mode: operational teams can fulfil access quickly, but without governance-owned standards, they cannot prove whether access was appropriate, time-bound, or later reconciled.

For that reason, best practice is to separate decision rights from task completion. IAM or access governance should own entitlement models, approval policy, segregation-of-duties checks, and periodic access certification. IT can keep the workflow moving, but it should not be the source of truth for who gets what access. These controls tend to break down when ticket queues are treated as the system of record in highly outsourced environments because vendor fulfilment teams often optimise for speed and close tickets without validating policy intent.

Common Variations and Edge Cases

Tighter governance often increases cycle time, so organisations have to balance access speed against control assurance. That tradeoff is especially visible in small teams, mergers, and shared-service environments where the same people may wear IAM, ITSM, and platform support hats.

There is no universal standard for this yet, but current guidance suggests a few practical variations. In a highly centralised model, IAM owns both approval policy and fulfilment orchestration, which works well when access risk is high and entitlement complexity is manageable. In a federated model, application owners may approve business use, while identity governance still owns policy definitions, review frequency, and exception tracking. In regulated environments, the strongest pattern is to keep approvers separate from fulfiller roles and to require periodic reconciliation against the access catalog.

Edge cases usually appear where access is not delivered through a normal ticket path, such as emergency elevation, service account changes, or temporary contractor access. Those requests should still follow the same governance owner, because urgent fulfilment without policy review is how exceptions become standing access. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful reference for treating access as a lifecycle, not a one-time ticket. The operational lesson is simple: IT can move the request, but IAM must own the rules, the evidence, and the reconciliation.

Related resources from NHI Mgmt Group

• Who should own lifecycle governance across IAM and access controls?
• Who should own governance for AI-assisted developer access: IAM, engineering, or platform teams?
• Who should own ephemeral access governance across IAM and PAM?
• How do IAM teams decide whether an AI security assistant needs its own access controls?