A transit authority already runs ITSM and wonders whether implementing IRM will replace the service desk. How should the implementer position IRM?

ServiceNow IRM governs risk, policy, and compliance for organizational entities; it does not replace ITSM request and incident fulfillment. A transit authority that already runs a service desk should hear that the broken-badge ticket still belongs in Incident or Request Management, while IRM tracks whether badge policy, related risks, and control tests remain healthy for governed entities such as stations or applications. Platforms may integrate—issues can relate to incidents—but the core purpose of IRM is assurance content and posture, not desk operations. Closing Incident, Problem, and Change after IRM go-live is an incorrect big-bang that abandons service management. Calling IRM only a reporting skin over ITSM tickets denies the need for entities, controls, risks, and policy records of its own. Treating IRM and ITSM as the same product under two license SKUs collapses distinct CIS tracks and confuses architecture decisions. Exam caveat: CIS-RC positions IRM beside ITSM, not as a replacement for CIS-ITSM processes. Operational check for the transit authority: document a simple RACI where service-desk agents retain incident ownership, while control owners complete IRM attestations for the same service entity, and verify both record types can coexist without routing compliance solely through the ticket queue.