What should teams do when identity and collaboration controls are owned by different groups?

Create a single operating model for SaaS governance that assigns clear ownership for identity, device trust, sharing, and mail monitoring. If those controls sit in separate queues, drift is likely to persist because no team owns the combined risk. The benchmark only helps when accountability matches the control surface.

Why separate ownership creates a governance problem

When identity and collaboration controls sit in different queues, the issue is usually not the control itself but the handoff model. Teams end up optimizing their own slice of SaaS governance while no one owns the combined effect of identity, device trust, sharing, and message monitoring. That is how drift persists even when each group believes it is doing the right work.

The practical failure is fragmented accountability. If one team manages sign-in policy, another manages mailbox rules, and a third owns external sharing, the organisation may have policy coverage but not operational ownership. A single operating model closes that gap by defining who decides, who executes, and who is accountable for the full control surface.

That same logic applies to the identity security programme operating model: if the scope is split across functions without a common RACI, the control set will age unevenly and exceptions will accumulate.

What teams should standardize first

Start by treating the SaaS estate as one governance domain, not a collection of unrelated admin tasks. The first design choice is ownership for the shared control plane: identity policy, device compliance, collaboration settings, sharing restrictions, and monitoring thresholds should live under one operating model even if execution is federated.

That model should answer three questions clearly. Which team owns the standard? Which team administers exceptions? Which team validates that identity controls still align with collaboration settings after platform changes, acquisitions, or new app rollouts? Without those answers, every future review becomes a negotiation instead of a control decision.

For organisations building a broader lifecycle view, lifecycle management is a useful parallel because ownership, rotation, offboarding, and visibility must be handled as a single process rather than isolated events.

The operating model should also include evidence expectations. A control is not really owned until someone can produce the setting baseline, the exception register, the review cadence, and the alert path for drift or abuse. That is what turns governance from a policy statement into an enforceable process.

How to keep the control surface from drifting

Drift usually appears in the seams. One team changes conditional access, another relaxes external sharing for a business unit, and a third never updates the monitoring rules that should catch unusual mail forwarding or mass sharing. The result is a system that still looks governed on paper but no longer behaves like a single security model.

Teams should therefore align the operating model to change management, not only to role ownership. Any change that affects authentication, device trust, collaboration permissions, or mail monitoring should trigger a cross-control review. The point is not centralization for its own sake; it is to prevent a local change from creating an enterprise-wide gap.

That is why top identity and access issues often show up as ownership failures first: stale access, excessive permissions, and poor visibility are rarely just technical mistakes, they are usually signs that no one owns the combined lifecycle.

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	SaaS governance depends on clear ownership and review of user access across systems.
Recommendation — Centralise account ownership and review processes across collaboration and identity controls.
NIST SP 800-53 Rev 5	AC-2 — Account Management	Clear accountability is needed for account lifecycle, exceptions, and access review in shared SaaS control surfaces.
	AC-6 — Least Privilege	Separated teams often leave excess access or inconsistent permissions across identity and collaboration tools.
Recommendation — Assign accountable owners for account lifecycle and periodic access review. Enforce least privilege consistently across identity and collaboration administration.
ISO/IEC 27001:2022	A.5.15 — Access control	Unified governance is required when multiple groups manage related access controls in the same SaaS environment.
Recommendation — Define and operate a single access-control model across all SaaS controls.
CSA Cloud Controls Matrix	IAM — Identity and Access Management	Cloud SaaS governance needs one IAM operating model covering identity and adjacent collaboration controls.
Recommendation — Align SaaS governance ownership to a single IAM operating model.

Practitioner Guidance

What to prioritise: Define one accountable owner for the combined SaaS governance model before you try to optimize any individual control. If ownership is split, the strongest technical control can still fail at the boundary between teams.

What to verify: Confirm that every identity, device, sharing, and monitoring setting has an explicit owner, an exception path, and a review cadence. If any of those elements is missing, the control is not operationally complete.

Common mistake: Treating collaboration governance as an app-admin issue and identity governance as an IAM issue. In practice, the risk is created by their interaction, so the review process has to span both.

Practitioner takeaway: The benchmark only works when accountability matches the full control surface, otherwise teams inherit fragments of responsibility but none of the combined risk.