IAM should own the identity lifecycle rules, while SaaSOps should own the application inventory, renewal cadence, and business ownership data that make those rules actionable. The two functions need shared workflows for onboarding, access review, and offboarding. Without that split of responsibility, the organisation keeps either the licence record or the access record, but not both.
How to split accountability without splitting the control
Access control works best when one team owns the policy logic and another owns the business context that keeps the policy accurate. IAM can define the lifecycle rules for who should gain, keep, or lose access. SaaSOps then supplies the application facts that make those rules enforceable in real workflows, so reviews and removals are based on current service ownership rather than stale assumptions.
The practical test is whether the organisation can answer three questions at any time: which application is in scope, who is responsible for it, and when the access relationship should be reviewed or removed. If any of those answers lives only in one team’s system, the control becomes brittle even if the policy itself is sound.
That split is why shared responsibility matters more than shared awareness. IAM should not be expected to maintain app-by-app ownership data, and SaaSOps should not be asked to interpret identity lifecycle rules in isolation. The control is strongest when the policy engine and the service inventory remain separate but linked.
What each team needs to own day to day
IAM teams should own identity lifecycle rules, access patterns, and the control logic for provisioning, review, and offboarding. That includes how joiner, mover, and leaver events map to entitlement changes, and what conditions trigger access removal or revalidation.
SaaSOps should own the application inventory, renewal cadence, business owner mapping, and app-specific exceptions that affect whether access still makes sense. In practice, that means keeping the authoritative record of which business function uses the SaaS app, who approves access, and when subscriptions or access grants need renewal.
The handoff point is the workflow, not the data silo. For onboarding, IAM can define the access path while SaaSOps confirms the application is active, owned, and eligible. For access review, IAM can drive the control cycle while SaaSOps validates whether the app and approver details are still current. For offboarding, IAM can enforce removal while SaaSOps confirms which application relationships and business owners are affected.
Why this model breaks down when ownership is vague
When access control and application ownership are not aligned, organisations often end up with either a clean access record and a poor application record, or the reverse. That creates gaps in recertification, delayed deprovisioning, and weak exception handling because no one can prove whether access still maps to a legitimate business need.
This is especially important where SaaS applications have independent admin consoles, delegated role models, or approval workflows outside the central IAM stack. A central rule can still be correct while the local app record is out of date, and the result is stale access that survives because the business owner was never clearly assigned.
The reverse failure is also common: SaaSOps knows the application exists, but IAM has no durable rule for how that access should be granted or revoked. In that case, teams rely on manual tickets and tribal knowledge, which makes the control hard to audit and hard to repeat.
Risk and Threat Considerations
Weak responsibility splits create real exposure because stale ownership and stale access tend to reinforce each other. If application inventory, renewal data, and business ownership are not current, accounts can remain active after role changes, app retirements, or vendor turnover, which increases the chance of unauthorized access persisting unnoticed.
Failure mechanism: The lifecycle rule exists, but the application data needed to execute it is incomplete or outdated, so review, renewal, and deprovisioning decisions are made against the wrong business context.
Impact: Orphaned access, delayed removal, and unowned exceptions become more likely, and the organisation loses confidence that access decisions match current business need.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Access control here depends on authoritative account ownership and lifecycle handling. |
| Recommendation — Centralize account inventory, approval, and revocation workflows for SaaS access. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The split between IAM and SaaSOps is an account lifecycle governance problem. |
| AC-6 — Least Privilege | Access reviews and renewals should keep permissions limited to current business need. | |
| Recommendation — Assign lifecycle ownership for provisioning, review, and disabling accounts. Restrict entitlements to the minimum access justified by current ownership. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The page is fundamentally about how access control responsibilities are shared and governed. |
| A.5.18 — Access rights | Renewal, review, and removal of SaaS access are access-rights lifecycle activities. | |
| Recommendation — Define and enforce access control responsibilities across IAM and SaaSOps. Review and remove access rights on a recurring, owner-verified basis. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud SaaS access governance sits directly within IAM ownership and controls. |
| Recommendation — Map SaaS access approvals, reviews, and revocation to IAM governance. | ||
Practitioner Guidance
What to prioritise: Define a single accountable owner for the identity lifecycle rule set and a single accountable owner for the SaaS application record, then make the workflow show both names on every review and offboarding action. If either owner is missing, treat the control as incomplete rather than merely pending.
What to verify: Check that every application in scope has a current business owner, a renewal date, and a clear review path before you rely on access recertification results. If the review evidence does not point to an identifiable app owner, do not treat the certification as meaningful.
Common mistake: Teams often centralise the approval step but leave ownership data scattered across spreadsheets, ticketing systems, and SaaS consoles. That makes the process look governed while still allowing access drift underneath it.
Practitioner takeaway: Good access control is not just who can approve access, but whether the organisation can continuously prove which application, owner, and lifecycle event justify that access.
Related resources from NHI Mgmt Group
- How do IAM and PAM teams share responsibility for database credential control?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?