How should security teams govern access requests through IT service management tools?

Why This Matters for Security Teams

IT service management tools often become the front door for privileged access, but the workflow is only safe when it is governed like an identity control, not a help desk convenience. If access approvals live only in tickets, security teams lose the ability to prove who approved what, under which authority, and for how long. That gap is especially dangerous for NHIs and service accounts, where entitlement sprawl can persist unnoticed.

Current guidance from the NIST Cybersecurity Framework 2.0 emphasizes governance, traceability, and access accountability, while NHIMG research on Ultimate Guide to NHIs shows how quickly unmanaged access becomes a broader identity risk. The practical issue is not whether the ticket was closed, but whether the decision can withstand audit, incident response, and access review months later.

In practice, many security teams discover weak access governance only after a privileged entitlement is abused or an auditor asks for proof that no one can easily assemble.

How It Works in Practice

The strongest pattern is to treat the ITSM record as a governed access decision, then synchronize it with identity and privilege systems. Each request should capture the requester, approver, business justification, entitlement scope, target system, duration, and expiration. That record should then drive provisioning, not merely document it.

For human users, this usually means tying the ticket to a named manager or system owner, plus a separate control for privileged or sensitive access. For NHIs, the same workflow should include workload ownership, service purpose, and explicit constraints on the secret, token, or API scope being issued. NHIMG’s Lifecycle Processes for Managing NHIs and Regulatory and Audit Perspectives both reinforce that lifecycle evidence matters as much as access itself.

• Require a unique approval trail per entitlement request, not a shared “team approval.”
• Bind the ticket to the exact role, group, account, or secret that will be granted.
• Set an expiry or review date so standing access is not created by accident.
• Export ticket data into IAM, PAM, or IGA tooling so approvals are enforceable and reviewable.
• Retain immutable logs for later attestation, incident response, and recertification.

Security teams should also align this flow with the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0, especially where approvals touch secrets, service accounts, or third-party integrations. The goal is to ensure a ticket cannot outlive the authorization it represents. These controls tend to break down when the ITSM tool is disconnected from provisioning systems and approvals are manually rekeyed into downstream platforms.

Common Variations and Edge Cases

Tighter access workflows often increase ticket volume and approval latency, so organisations must balance speed against assurance. That tradeoff is especially visible in operations teams that need fast break-glass access, vendor support access, or recurring admin privileges.

Best practice is evolving for these cases. There is no universal standard for how much ticket detail is sufficient, but current guidance suggests the approval record should be proportional to risk. Low-risk requests may need a manager and system owner; high-risk or privileged access should involve PAM, time limits, and stronger review. For NHIs, the same principle applies to secrets and tokens, where long-lived access should be treated as exceptional rather than normal.

One NHIMG finding worth noting is that only 20% of organisations have formal offboarding and revocation processes for API keys, while 71% of NHIs are not rotated within recommended time frames. That context makes it risky to treat ITSM closure as the end of the control. If the ticket does not trigger revocation, rotation, or periodic recertification, the approval history becomes evidence without enforcement.

Edge cases also include emergency access, delegated approvals, and automated request fulfilment. Those patterns can be acceptable, but only when the exception path is logged, time-bound, and later reviewed. Without that discipline, the ticketing system becomes a record of intent rather than a control over access.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern Active Directory service accounts?
• How should security teams govern access requests for both users and service accounts?