The organisation can remove licences without removing accounts, or keep accounts active without any clear business need. That split leaves shadow access in place, weakens ownership, and produces a false sense of control because the finance view and the identity view never meet.
Where the split starts to fail
saas spend management answers one question, namely what software is paid for. Identity governance answers a different question, namely who still has access and whether that access is still justified. When those two views are separated, the organisation can optimise licences while leaving active accounts, entitlements, and shared access paths untouched.
The practical failure is not only waste, but incomplete control. A subscription can be terminated on paper while the underlying account still exists, or a user can be deprovisioned in one system while access remains active in the SaaS tenant. That gap is where ownership breaks down and where access reviews lose their meaning.
In IAM and IGA Basics, the distinction between provisioning, access review, and entitlement governance is the exact control boundary that gets blurred when finance and identity are not connected.
What the organisation loses when finance and identity do not meet
Separating the processes creates a false sense of precision. Finance may report a licence reduction, while identity teams still see dormant users, orphaned accounts, or excessive permissions inside the application. That mismatch means the business believes it has reduced exposure when it has only reduced cost.
It also weakens accountability. If no single workflow owns the full joiner, mover, leaver path, then one team can say the licence was removed and another can say the account was never formally deprovisioned. The result is ambiguous ownership, slower remediation, and harder audit evidence.
The Joiner-Mover-Leaver (JML) Guide is relevant because the break usually appears at offboarding and role change, where entitlements should be removed at the same time as commercial access is ended.
Identity Security Posture Management (ISPM) Guide fits here as well, because posture drift is often visible before a licence report reveals the problem.
How to close the control gap without overcomplicating the workflow
The cleanest model is a shared decision path: the business owner decides whether the service is still needed, identity governance confirms what access exists, and SaaS operations or procurement confirms what is still billed. Those checks should happen in the same lifecycle event, not as separate monthly reconciliations with different owners and different evidence standards.
That same pattern matters for reviews. An access review that only asks, “Should this user keep the licence?” is too narrow. A useful review asks whether the account should exist, whether the entitlement is still required, and whether the application contains any privileged or shared access that must be removed or downgraded.
Access Reviews and Certification Guide supports that closed-loop approach, because review outcomes have to drive removal, not just produce a report.
IGA Buyer’s Guide is useful when teams need to evaluate whether their tools can actually connect lifecycle events, disconnected applications, and entitlement cleanup.
Risk and Threat Considerations
When licence management and identity governance are split, stale access becomes easy to miss and hard to prove removed. That creates shadow access, excessive privilege, and weak auditability, especially in SaaS estates where accounts, tokens, and delegated access can outlive the commercial subscription decision.
Failure mechanism: Licence removal is treated as a financial action instead of an access-control action, so the application account, role membership, or downstream entitlement remains active after the business no longer wants it.
Impact: Unneeded access can persist unnoticed, expanding the blast radius of compromise, weakening ownership, and undermining assurance that leavers and role changes were actually completed.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Licence and account split leaves credentials and access active past need. |
| AC-2 — Account Management | The issue is unmanaged account lifecycle after SaaS spend changes. | |
| AU-2 — Event Logging | Unified evidence is needed to prove access removal and ownership. | |
| Recommendation — Tie licence removal to authenticator revocation and credential cleanup. Synchronise account disablement with application offboarding. Log lifecycle events that connect licence changes to account removal. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Access rights must be removed when business need ends, not just licences. |
| A.5.16 — Identity management | The question is about who remains governed after spend actions. | |
| Recommendation — Review and revoke access rights when SaaS use is no longer justified. Link identity lifecycle controls to SaaS procurement and renewal. | ||
Practitioner Guidance
What to prioritise: Tie every licence change to an account-state decision. If the person or service no longer needs the application, the workflow should remove the account or confirm a deliberate exception, not just cancel billing.
What to verify: Ask whether your evidence can show the account was disabled or deleted, the entitlements were removed, and any shared or privileged access was reviewed at the same time as the licence was reclaimed.
Common mistake: Treating spend dashboards as if they were access-control evidence. A lower SaaS bill is not proof that access has been removed, and a deprovisioned user is not proof that every application account was cleaned up.
Practitioner takeaway: The control only works when commercial offboarding and identity offboarding are one workflow, because separating them leaves the organisation with cost savings on paper and residual access in practice.
Related resources from NHI Mgmt Group
- What breaks when secrets management is treated as machine identity governance?
- What breaks when mobile access is treated separately from identity governance?
- What happens when AI governance is treated separately from SaaS security and identity security?
- What is the difference between attack surface management and NHI governance?