Provisioning grants access at the start of employment or engagement. Lifecycle governance also covers revocation, ownership transfer, entitlement recovery, and evidence capture when that access ends or changes, across both managed and unmanaged apps.
Provisioning is the start, governance is the whole control plane
Provisioning access answers a narrow question: who gets access, to what, and when it begins. SaaS lifecycle governance answers a broader one: who owns the access, how long it should exist, what happens when the role changes, and how the organisation proves that the access was removed or transferred correctly. That difference matters because the control objective changes from grant-only to continuous entitlement stewardship.
In practice, provisioning is usually a one-time or event-driven action, often triggered by joiner, mover, or project onboarding workflows. Governance spans the full lifecycle of the account and the entitlement, including review, recertification, reassignment, revocation, and evidence retention. IAM and IGA Basics is a useful reference point for separating access requests from access governance.
The distinction becomes sharper in SaaS because the app itself may be managed, lightly managed, or effectively unmanaged by the business. Lifecycle governance has to account for ownership transfer, stale entitlements, orphaned accounts, and access recovery when employees move between teams or leave entirely. Joiner-Mover-Leaver (JML) Guide shows why mover and leaver events are where most governance failures surface.
What lifecycle governance adds after access has been provisioned
Once access exists, governance focuses on whether that access still matches business intent. That includes entitlement ownership, periodic access review, removal of unused permissions, transfer of responsibility when a SaaS app changes owners, and recovery of access evidence for audit or dispute resolution. If provisioning is the act of creating access, governance is the discipline that keeps the access accurate, attributable, and reversible.
This is also where unmanaged or shadow SaaS creates the biggest gap. A team can provision access into a centrally known app, yet still miss accounts created directly by admins, OAuth grants, shared logins, or long-lived tokens outside the normal lifecycle process. NHI Lifecycle Management Guide is relevant because the same lifecycle problem often extends into tokens, service accounts, and other identity-bearing material used by SaaS integrations.
Governance also means deciding what evidence must exist after the fact. A healthy process can show who approved the access, who owns it now, when it was last reviewed, and how revocation or transfer was completed. Without that evidence, provisioning may be technically correct but operationally ungoverned.
Why the difference matters for control, audit, and cleanup
Provisioning alone is easy to overvalue because it creates the visible start of access. The harder risk sits at the end of the lifecycle, where access should shrink, move, or disappear. That is why SaaS governance is tied to access recertification, orphan detection, entitlement recovery, and offboarding quality, not just initial onboarding speed. Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs provides a parallel lifecycle model that helps explain why end-state control is as important as access creation.
The operational difference is especially important when ownership changes. A SaaS account can be provisioned correctly and still become risky if no one owns the app, the business sponsor changes, or the application outlives the team that requested it. In those cases, governance is what prevents access from becoming permanent by accident.
For teams that must prove control effectiveness, lifecycle governance is the part that stands up in review: it shows not only that access was granted, but that the organisation can also revoke, reassign, and document the change without losing accountability.
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 | Directly governs account lifecycle, provisioning, review, and removal for SaaS access. |
| AC-6 — Least Privilege | Lifecycle governance should prevent lingering access beyond current job needs. | |
| AU-2 — Event Logging | Governance needs audit evidence for approvals, changes, and removals in SaaS access. | |
| Recommendation — Implement AC-2 to manage provisioning, review, transfer, and revocation across the SaaS lifecycle. Apply AC-6 to keep SaaS entitlements limited to current business need and role. Use AU-2 to log access changes and preserve evidence for lifecycle decisions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Covers governing access rights beyond initial provisioning, including ongoing management. |
| A.5.18 — Access rights | Addresses granting, review, modification, and removal of access rights. | |
| A.5.16 — Identity management | Identity ownership and reassignment underpin SaaS lifecycle governance. | |
| Recommendation — Use A.5.15 to govern access rights through their full lifecycle. Apply A.5.18 to ensure access rights are reviewed and removed when no longer needed. Use A.5.16 to keep identity ownership and lifecycle changes controlled. | ||
| CIS Controls v8 | CIS-5 — Account Management | Directly aligns to account provisioning, review, and removal across SaaS apps. |
| Recommendation — Implement CIS-5 to govern SaaS account creation, maintenance, and removal. | ||
| OWASP ASVS | V8 — Authorization | Authorization governs what access remains valid after provisioning. |
| Recommendation — Apply V8 to validate that SaaS permissions still match intended access. | ||
Practitioner Guidance
What to prioritise: Treat provisioning as the entry point and governance as the operating model. If your process can grant access but cannot show who owns it, when it was last reviewed, and how it is removed or transferred, you have onboarding, not lifecycle control.
What to verify: Confirm that every SaaS app has a named owner, a revocation path, and an evidence trail for mover and leaver events. For apps outside central IT control, verify that the business still knows how to recover or withdraw access when the owner changes.
Common mistake: Measuring success by provisioning speed alone. Fast access creation is useful, but without review and deprovisioning discipline it increases entitlement drift and makes cleanup slower and riskier later.
Practitioner takeaway: Provisioning answers how access starts, but governance determines whether access stays accurate, attributable, and removable over time.
IAM and IGA BasicsRelated resources from NHI Mgmt Group
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between protecting applications and protecting access?
- What is the difference between blocking a compromised OAuth application and continuously governing SaaS-to-SaaS access?
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 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org