Keep ITSM for service requests, incidents, and change workflows, but stop using it as the system that decides entitlement scope. IAM teams should route access through a policy engine, preserve the audit trail, and reserve manual review for high-risk or exception cases.
Why ITSM Should Keep the Workflow, Not the Decision
ITSM is still the right place to receive requests, route incidents, and manage change records, but it should no longer be the authority that decides who gets which entitlement. Once access governance is added, the decision point moves to the policy layer, where roles, rules, approval logic, and risk checks are enforced consistently instead of being embedded in ticket handling.
This split matters because request handling and entitlement decisioning solve different problems. ITSM is optimized for intake, tracking, and auditability; access governance is optimized for entitlement scope, segregation of duties, and policy-based approval. Conflating the two often creates duplicate logic, inconsistent approvals, and a false sense that a ticket itself equals compliant access.
For teams modernising access operations, the cleanest pattern is to treat ITSM as the orchestration front end and the access governance or policy engine as the system of record for entitlement decisions. That preserves the service desk workflow users already know while ensuring the actual access outcome is governed by rules rather than by the wording of a request.
Where the Policy Engine Fits in the Access Flow
Access requests should enter through ITSM, but the request should be evaluated by a policy engine that can interpret role, entitlement, risk, approval, and exception logic. That engine can decide whether the request maps to a standard entitlement, requires compensating approvals, or should be blocked because it conflicts with policy. In other words, ITSM carries the work, while the governance layer carries the decision.
This approach is especially important when access scope depends on context such as job function, application sensitivity, environment, or segregation of duties. A ticketing workflow alone usually cannot evaluate those conditions reliably at scale. A policy engine can enforce them repeatably, while ITSM records the business justification, timestamps, approvers, and closure evidence.
IAM and IGA Basics is a useful reference for the boundary between request handling and entitlement governance. For organizations formalising role models, Role Mining and Role Design Guide helps keep entitlement decisions anchored to roles rather than ad hoc tickets.
In practice, the policy engine should also publish the final access decision back into ITSM so the ticket remains the audit wrapper. That way, auditors and reviewers can see who asked, what was approved, which policy was applied, and what was provisioned without forcing the ticketing tool to become the entitlement brain.
What to Preserve, What to Remove, and What Needs Manual Review
The key design goal is not to eliminate ITSM, but to remove entitlement logic from it. Keep ITSM for intake, status, evidence capture, escalation, and change coordination. Remove from ITSM any hard-coded role catalogues, approval matrices that drift from policy, or manual routing rules that try to decide access by exception. Those decisions belong where access rules can be centrally governed and reviewed.
Manual review still has a place, but only for cases that are genuinely high risk, unusual, or outside policy. That includes exceptions, toxic combinations, privileged access, and requests that cannot be satisfied by a standard entitlement path. Routine access should not depend on human interpretation of ticket text, because that creates bottlenecks and inconsistent outcomes.
The practical test is simple: if the question is “did the user need this access, and is it allowed?” the policy layer should answer it; if the question is “what happened to the request, who touched it, and when was it fulfilled?” ITSM should answer it. That separation keeps operational workflow intact without letting the service desk become the control plane for authorization.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | ITSM requests often feed access provisioning and review workflows. |
| AC-6 — Least Privilege | Entitlement scope should be policy-driven to avoid over-assignment. | |
| AU-2 — Event Logging | ITSM should preserve the audit trail for access decisions and changes. | |
| Recommendation — Route access requests to governed account workflows and keep ticketing as evidence, not the decision source. Enforce least privilege in the policy layer and reject ticket-based entitlement expansion. Log the request, approval, and provisioning outcome so ITSM remains an auditable wrapper. | ||
| CIS Controls v8 | 5 — Account Management | Access requests and revocation should be governed centrally, not ad hoc in tickets. |
| 6 — Access Control Management | Policy-based access decisions are the control objective described in the question. | |
| Recommendation — Use ITSM to orchestrate requests, but centralize account and entitlement governance in IAM tooling. Apply centralized access control logic to decide entitlements and reserve ITSM for workflow tracking. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about separating access decisions from service workflow handling. |
| A.8.2 — Privileged access rights | High-risk access should be exception-handled rather than ticket-decided. | |
| Recommendation — Define access control rules outside ITSM and make ticketing record the approved outcome. Treat privileged access as governed exceptions and retain manual review only where risk warrants it. | ||
| OWASP ASVS | V8 — Authorization | The access decision belongs to authorization logic, not request intake. |
| Recommendation — Keep authorization decisions in a dedicated policy layer and avoid embedding them in workflow tickets. | ||
Practitioner Guidance
What to prioritise: Separate request orchestration from entitlement decisioning first, then clean up any workflow rules in ITSM that still encode access policy. If a ticket can approve access by itself, the governance model is still too dependent on workflow logic.
What to verify: Confirm that every entitlement granted through ITSM is actually resolved by a policy engine, role rule, or governed exception, and that the ticket only stores the resulting decision and evidence. If the ticket contains the policy logic, access governance is not really centralized.
Common mistake: Teams keep the old approval form, add a policy engine behind it, and assume the redesign is complete. The result is usually duplicate approvals, unclear ownership, and manual review of standard requests that should have been automated.
Practitioner takeaway: Keep ITSM as the front door and the audit trail, but make sure entitlement scope is decided once, in the governance layer, so access decisions stay consistent, reviewable, and scalable.
Related resources from NHI Mgmt Group
- How should IAM teams improve access request governance without adding friction?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- What is the difference between role-based access and API key governance for NHI security?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org