Why do SaaS programmes need ITAM as well as ITSM?

Why This Matters for Security Teams

SaaS programmes fail when service management is treated as the whole control plane. ITSM is built to fulfil requests, incidents, and changes, but it does not by itself preserve an accurate inventory, licence entitlement history, or ownership model for applications and integrations. That gap matters because hidden apps and stale access create spend leakage and security exposure at the same time.

This is not just a theory problem. NHI Management Group research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. The same pattern appears in SaaS when the programme can approve, but not continuously reconcile, what is actually in use. That is why ITAM has to sit alongside ITSM, with lifecycle and inventory controls informed by a broader governance view such as the NIST Cybersecurity Framework 2.0 and NHIMG guidance in the Ultimate Guide to Non-Human Identities.

In practice, many security teams discover the missing asset record only after a breach review, a licence true-up, or an access recertification exposes how much has been accumulating outside service workflows.

How It Works in Practice

ITAM and ITSM solve different parts of the SaaS problem. ITSM manages the workflow of demand, approval, fulfilment, incident handling, and change. ITAM maintains the system of record for what the organisation owns, who is accountable, what licences are assigned, where applications are deployed, and when retirement should happen. For SaaS, that record must also include subscriptions, admin roles, integrations, connected identities, contract terms, and renewal dates.

A workable operating model usually connects the two systems rather than merging them. ITSM should trigger events that update ITAM, while ITAM should drive decisions back into ITSM. For example: a new SaaS request may be approved in ITSM, but ITAM should confirm vendor, owner, data classification, renewal date, and duplicate-tool risk before procurement completes. Likewise, an offboarding ticket should not close until ITAM confirms that licences, accounts, and integrations were actually removed.

• Use ITSM for request routing and approvals, but let ITAM own the authoritative application and licence register.
• Reconcile discovered SaaS against approved SaaS on a recurring basis, not only during procurement.
• Track business owner, technical owner, contract owner, and data steward separately where roles differ.
• Connect licence counts, renewal alerts, and retirement criteria to lifecycle workflow, not ad hoc email reminders.

For identity-heavy SaaS estates, this also aligns with non-human identity control. NHIs often outnumber human identities by 25x to 50x, so every orphaned SaaS integration or forgotten API token compounds risk. The Snowflake breach and Salesloft OAuth token breach show how quickly access can outlive the process that created it. These controls tend to break down when SaaS is procured by business units without central discovery because shadow subscriptions and embedded credentials never enter the official lifecycle.

Common Variations and Edge Cases

Tighter ITAM governance often increases process overhead, requiring organisations to balance control quality against speed of adoption. That tradeoff is most visible in decentralised SaaS buying, where business teams want fast procurement and security teams need enough evidence to avoid duplicate tools, inactive licences, and untracked integrations.

Best practice is evolving for shadow SaaS and embedded AI features. There is no universal standard for this yet, but current guidance suggests treating any externally managed app with data access as an asset, even if procurement did not originate in IT. That includes browser-installed extensions, department-owned CRM add-ons, and SaaS features that create their own service accounts or tokens. In those cases, ITSM tickets alone are insufficient because they describe a workflow event, not the asset lifecycle.

The most common edge case is “approved but unmanaged” software. A tool may be properly requested through ITSM, yet still lack contract metadata, owner assignment, or retirement criteria in ITAM. Another is vendor sprawl during renewals, where overlapping subscriptions continue because no one is accountable for rationalisation. NIST’s governance model supports this separation of operational workflow from asset accountability, and NHIMG’s findings on poor visibility into service accounts reinforce why SaaS programmes need both disciplines, not one or the other. The control model becomes fragile when federated purchasing, mergers, or regional exceptions allow local teams to renew SaaS independently because the central register no longer reflects reality.

Related resources from NHI Mgmt Group

• Why do SaaS management tools matter to identity governance programmes?
• Why do IAM programmes need to cover non-human identities as well as users?
• What breaks when ITAM or SAM is used to manage SaaS licences?
• Why do SaaS provisioning programmes often drift into over-provisioning?