Procurement should manage commercial terms, but IAM should govern entitlement ownership, account type, and removal conditions. The two functions need a shared process so renewal decisions are based on actual access need rather than historical allocation or budget habit.
Who should own which part of SaaS license management?
Ownership works best when the commercial and security questions are separated but joined by a shared workflow. Procurement should own the buying decision, renewal negotiation, and contract terms. IAM should own who is entitled, what account type is used, and when access must be removed. That split prevents budget decisions from accidentally becoming access decisions.
The practical question is not who “buys” the license, but who can answer whether the access is still justified. In SaaS environments, the license is often tied to an account, role, or tenant entitlement, so the ownership model has to cover both commercial consumption and access governance. Identity Security Programme Guide is useful here because it frames the operating model and RACI needed to keep those responsibilities clear.
For teams that already have a strong identity lifecycle process, SaaS license management should fit into that lifecycle rather than sit beside it. That means new access should follow request and approval paths, inactive users should be reviewed on a schedule, and departures or role changes should trigger removal or downgrade. NHI Lifecycle Management Guide and Lifecycle Processes for Managing NHIs both support that lifecycle view, especially where SaaS access is granted to shared, delegated, or service-type accounts.
The account type matters because not every SaaS seat represents the same risk. A named user, a shared account, an admin account, and a service account have different review rules, different removal triggers, and different blast-radius implications. When IAM and procurement treat them as interchangeable line items, organisations tend to keep paying for access that is no longer aligned to actual use. Top 10 NHI Issues helps anchor the access-governance side of that problem.
Renewal review should therefore ask three separate questions: is the license still needed, is the account still active, and is the privilege level still appropriate? That sequence is important because spend optimisation alone can miss orphaned access, while access review alone can miss commercial waste. A shared process lets procurement see utilisation and lets IAM see entitlement status before any renewal decision is finalised.
Where SaaS license management breaks down in practice
Failures usually come from ownership gaps rather than from the license system itself. Procurement may renew based on seat counts or renewal calendars, while IAM may only see the account inventory after the contract has already been extended. The result is stale access, overprovisioned roles, and a false sense that a licence is “in use” simply because it was allocated once.
Another common failure is treating access removal as an end-user offboarding task only. In SaaS, unused seats can still carry active tokens, delegated permissions, API access, or administrative reach. Cloud Workload Identity Guide is relevant where SaaS platforms integrate with automation, CI/CD, or other non-interactive access paths that should not be left out of the review process.
Visibility also breaks down when organisations rely on the procurement record as the source of truth for entitlement status. A contract can be current while the underlying account has become stale, shared, or overprivileged. That is why ownership should include a control for removal conditions, not just a record of who paid for the seat.
How to make the split between procurement and IAM work
The most reliable model is a single review workflow with two decision owners. Procurement owns commercial renewal, true-up, and vendor negotiation. IAM owns access attestation, account classification, and revocation criteria. The handoff point should be explicit: renewal cannot proceed until IAM signs off on active need, account type, and exception list.
What to verify: confirm that every paid SaaS seat can be mapped to an accountable user, account type, or approved exception. If that mapping does not exist, the organisation cannot distinguish a legitimate renewal from historical drift.
Common mistake: using licence utilisation as a proxy for entitlement legitimacy. High utilisation does not prove justified access, and low utilisation does not always mean the licence can be removed if the account supports a workflow or delegated function.
What good looks like: procurement and IAM review the same renewal packet, use the same deprovisioning criteria, and track exceptions that justify keeping access beyond normal employment or role need. That alignment turns licence management into a governance control instead of a budget exercise.
Practitioner takeaway: let procurement own the commercial commitment, but let IAM own the access truth. If those teams do not share a common review process, SaaS renewals will keep preserving access that nobody can clearly justify.
Risk and Threat Considerations
SaaS licence sprawl is a governance and security exposure because unused or misclassified accounts can remain active long after the business case has changed. The risk is not only wasted spend, it is unnecessary access, especially where licences are tied to privileged, shared, or integrated accounts.
Failure mechanism: procurement renews on spend history while IAM has no enforced role in entitlement review, so stale accounts, overprivileged users, and delegated access paths survive the renewal cycle.
Impact: the organisation keeps paying for access that can later be abused for data exposure, lateral movement, or unauthorised action, and it loses the ability to prove that access was removed when need ended.
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, NIST CSF 2.0, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | License lifecycle decisions hinge on managing active credentials and removal conditions. |
| AC-2 — Account Management | SaaS license ownership depends on account inventory, classification, and deprovisioning rules. | |
| Recommendation — Tie renewal to credential and access revocation evidence before extending seats. Review account status and remove inactive or orphaned SaaS accounts before renewal. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | The question is about who governs access entitlement versus commercial purchase ownership. |
| Recommendation — Assign entitlement governance to IAM and use renewal as an access recertification checkpoint. | ||
| CIS Controls v8 | CIS-5 — Account Management | SaaS seat management is fundamentally about maintaining accurate account ownership and removal. |
| Recommendation — Maintain authoritative account records and disable access when business need ends. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud SaaS licence ownership maps directly to cloud identity, entitlement and revocation controls. |
| Recommendation — Use IAM to govern entitlement reviews, access removal, and exception handling for SaaS seats. | ||
Practitioner Guidance
Decision rule: if the SaaS seat is attached to any account that can access production data, administrative functions, or connected systems, require IAM sign-off before procurement renews it. Treat that as an access decision first and a commercial decision second.
What to prioritise: build a seat-to-account inventory that distinguishes named users, shared accounts, admins, and service integrations. That classification is the only way to apply different removal rules without arguing case by case during renewal.
Evidence to retain: keep the renewal request, the entitlement review, the exception rationale, and the removal ticket together. If those artefacts are separate, teams usually cannot reconstruct why an access path remained live.
Practitioner takeaway: the best SaaS license process is one where procurement can answer “what did we buy?” and IAM can answer “who should still have it?” without either team guessing.