No. In SaaS environments, configuration change and access change usually happen together, so the two disciplines need shared controls and shared evidence. Change management can show what moved, but identity governance must show whether access still matches intent after the move. Separate teams can work, but separate control logic creates blind spots.
Why SaaS Change and Identity Governance Need Shared Controls
In SaaS, the practical question is not whether change management and identity governance are different disciplines, but whether they can be controlled separately without losing visibility. The answer is usually no, because a configuration change often alters entitlements, roles, sharing, automation, or integration paths at the same time. If you govern them apart, you can approve the release and still miss the access consequences.
SaaS platforms make this coupling stronger than many on-premises systems. Admin consoles, tenant settings, app permissions, SCIM provisioning, API tokens, and delegated roles can all shift during the same change window. Shared evidence is therefore more useful than separate sign-off paths, especially when the change affects who can act, not just what the application does. The identity lifecycle view in IAM and IGA Basics is a useful reference point for that combined control model.
That is why the strongest operating model treats change records and identity records as two views of the same event. Change management should show the technical delta, while identity governance should show whether the delta created new access, widened privilege, or left obsolete access behind. If those evidence streams are not linked, teams tend to over-trust the release record and under-check the access posture.
Where Separation Breaks Down in Practice
The biggest failure mode is a clean change ticket paired with an unchanged access report. That often means the report is too early, too shallow, or scoped to the wrong system boundary. In SaaS, access can change indirectly through group membership, delegated administration, role templates, or connector logic, so a “no access change” conclusion may be false even when no one edited a user record by hand.
Another common issue is ownership drift. Change teams usually know what was deployed, but identity teams know whether the new state is still compliant with role design, segregation of duties, and recertification expectations. The gap becomes acute after emergency fixes, tenant-wide configuration edits, or connector updates that affect provisioning and deprovisioning. A general lifecycle reference such as NHI Lifecycle Management Guide is relevant here because the same lifecycle logic applies to access paths created or removed by SaaS change.
When organisations split the disciplines too far, they also create audit friction. Auditors and internal reviewers usually want to see both the reason for change and the resulting access state. If those artefacts live in different workflows, the organisation has to reconstruct the evidence after the fact, which is expensive and error-prone. A combined view also makes it easier to detect privilege creep and stale access after repeated SaaS releases.
What Good Joint Control Looks Like
Good practice is to join the control points, not the teams. A release should trigger identity impact analysis, and identity changes should be traceable back to the change record that caused them. That does not require one team to own everything, but it does require one control model and one evidence chain. Access Reviews and Certification Guide and Segregation of Duties (SoD) Guide both support this shared-evidence approach because they make the post-change access check explicit.
Practitioners should look for three concrete properties: the change record identifies which access paths may have moved; the identity workflow confirms whether entitlements, roles, or service permissions changed; and the review trail shows who verified the result. That pattern is especially important in SaaS environments where connector behaviour and delegated administration can change silently. IGA Buyer’s Guide is useful for evaluating platforms that can connect lifecycle, requests, reviews, and policy enforcement without forcing a manual reconciliation step.
At scale, the question becomes whether change and identity events can be correlated quickly enough to detect over-privilege before it becomes routine. If the answer is no, the organisation is relying on manual memory rather than control design. In SaaS, that is usually the point where shared dashboards, shared approvals, or event-driven recertification become more valuable than separate team ownership.
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 | AC-2 — Account Management | SaaS changes often alter accounts, roles, and entitlements. |
| CM-3 — Configuration Change Control | The question is about managing configuration change in SaaS environments. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Shared evidence and post-change verification depend on reviewable audit trails. | |
| Recommendation — Tie SaaS release approvals to account and entitlement review before promotion. Require formal change approval and traceable configuration baselines for SaaS updates. Correlate change and identity events in audit logs to verify effective access after release. | ||
| ISO/IEC 27001:2022 | A.8.32 — Change management | SaaS configuration changes need controlled approval and testing. |
| A.5.18 — Access rights | Identity governance must confirm that access still matches intent after change. | |
| Recommendation — Apply controlled change processes to SaaS tenant and integration changes. Review and recertify access rights after SaaS changes that affect permissions. | ||
Practitioner Guidance
What to prioritise: Tie the access-impact check to the same release or configuration workflow that approves the SaaS change. If the change can affect roles, groups, tokens, connectors, or delegated admin, identity review should be part of the release path, not a later housekeeping task.
What to verify: Confirm that the post-change state is compared against intended access, not just against the change request. The useful evidence is a before-and-after view of the effective permissions, plus a record that exceptions were reviewed and accepted by the right owner.
Common mistake: Treating “separate teams” as a reason for separate controls. Division of labour is fine; division of evidence is not. If the teams cannot jointly explain what changed and who can now do what, the control design is incomplete.
Practitioner takeaway: In SaaS, change management and identity governance can be separate functions, but they should not be separate control systems. The safest model is shared evidence, linked approvals, and a single view of how configuration changes affect access.
Related resources from NHI Mgmt Group
- Should organisations separate identity governance and SaaS management workspaces in a single platform?
- Why do organisations struggle to fund identity governance without SaaS management data?
- Why do organisations need separate rules for user identity and user-to-app relationships in SaaS governance?
- What do organisations get wrong about identity governance in hybrid and SaaS environments?