Microsoft 365 governance now depends on shared accountability

At a glance

What this is: This is a governance analysis of Microsoft 365 that argues control breaks down when ownership, visibility and delegated execution do not keep pace with growth.

Why it matters: It matters to IAM practitioners because Microsoft 365 governance now spans access, lifecycle, workspaces and AI-assisted collaboration, so identity controls must support shared accountability rather than central admin alone.

Context

Microsoft 365 governance is the operating model that decides how access, collaboration, protection and disposal work across Teams, SharePoint, OneDrive and Power Platform. The problem is not a lack of tools but a governance gap: organisations often centralise policy without distributing ownership and execution.

That gap becomes sharper as copilots, agents and cross-tenant collaboration increase the blast radius of weak workspace controls. The article's core claim is that governance now fails unless IT, compliance and business units share accountability for the spaces they create and the data they manage.

The underlying issue is familiar across identity programmes: visibility, ownership and policy only work when the operating model matches the way people and non-human actors actually use the platform.

Key questions

Q: What breaks when Microsoft 365 governance is owned only by central IT?

A: Central-only ownership usually breaks at scale because the admin team cannot keep up with workspace creation, ownership changes, guest access and configuration drift. The result is shadow IT, stale permissions and orphaned workspaces that no one reliably reviews. Shared accountability is the practical alternative because it preserves policy control while pushing operational responsibility to the teams creating the workspaces.

Q: When should organisations prioritise workspace ownership over more automation?

A: Ownership should come first whenever workspaces can be created faster than they can be reviewed. Automation cannot compensate for unknown or unassigned responsibility, because it will only enforce the wrong baseline more efficiently. Once every workspace has a clear owner and an agreed operating model, automation becomes useful for recertification, drift detection and lifecycle cleanup.

Q: What are the signs that Microsoft 365 compliance controls are failing in practice?

A: Common warning signs include untracked tenants, settings that drift away from the baseline, missing audit records, and changes that are not tied to a clear owner or approval trail. If teams cannot quickly tell what changed, who changed it, and whether the environment still matches policy, compliance is already degrading and likely to worsen over time.

Q: How should teams balance delegated administration with governance accountability?

A: Teams should separate policy authority from operational execution. Compliance and security teams define the rules, while business units or regional admins operate within those rules for the workspaces they own. That model scales better than central control and avoids the trust gap that appears when everyone can create, but no one is clearly accountable.

Technical breakdown

Why Microsoft 365 governance breaks at the workspace layer

Microsoft 365 governance fails most often at the workspace layer because the unit of control is not a user, it is a shared container with changing owners, permissions and content. Teams, SharePoint sites and Power Platform assets accumulate risk when creation is easy but lifecycle control is weak. Governance therefore has to track ownership, configuration drift, retention and access recertification across thousands of workspaces, not just enforce tenant-wide policy. This is where conventional admin-only control starts to miss the real exposure. See the NHI Ownership and Accountability Guide.

Practical implication: Treat workspace lifecycle and ownership as first-class controls, not an afterthought to tenant administration.

How shadow IT turns into unmanaged identity and access sprawl

Shadow IT in Microsoft 365 is usually a governance failure, not malicious behaviour. When business users can create Teams, apps and sites faster than central teams can review them, the result is permission sprawl, stale guests and ownerless resources. The identity angle matters because the same access model that enables collaboration also governs whether external users, service principals and app permissions remain appropriate over time. In practice, unmanaged self-service turns identity drift into data exposure. See the IAM and IGA Basics.

Practical implication: Map self-service creation paths to access review and offboarding controls before the sprawl becomes permanent.

Why least privilege and delegated administration must work together

Least privilege is necessary but not sufficient in Microsoft 365 because the platform is too large and too distributed for every change to flow through a central team. Delegated administration gives business units scoped operational control while policy authority remains central. That split matters for identity governance because it preserves accountability without collapsing into either bottlenecked central IT or uncontrolled self-service. Effective governance in Microsoft 365 depends on separating what people may do from where and how they may do it.

Practical implication: Use delegated administration to scale governance without weakening role boundaries or approval discipline.

NHI Mgmt Group analysis

Microsoft 365 governance has become an identity governance problem, not just a collaboration administration problem. The article is right to separate security from governance, because the harder challenge is not blocking threats but keeping thousands of workspaces owned, configured and reviewed in line with policy. Once Copilot, agents and cross-tenant collaboration enter the picture, access decisions become governance decisions as well. Practitioners should treat Microsoft 365 as an identity-controlled operating environment, not a document repository.

Shared accountability is the only governance model that scales in Microsoft 365. Central IT cannot own every workspace, while pure self-service guarantees drift. The practical middle ground is central policy with delegated execution, which aligns with named ownership and accountability and reduces the orphaned-workspace problem that drives most control failures. Practitioners should assign responsibility where workspaces are created, not only where platforms are administered.

Visibility before automation is the right sequencing for Microsoft 365 governance. Automating remediation on top of unknown ownership and unknown configuration only industrialises confusion. The article's sequence of visibility, ownership, policy and automation is the correct order because identity and lifecycle control must be established before scale amplifies the gaps. Practitioners should measure whether they can actually see workspace state before they try to optimise it.

Workspace sprawl is the governance debt Microsoft 365 teams now inherit. The named concept here is useful because the real issue is not simply too many assets, but too many assets with weak lifecycle, unclear ownership and inconsistent policy enforcement. That pattern is especially dangerous where AI features surface hidden access and expand the blast radius of overexposure. Practitioners should manage workspace sprawl as a standing identity governance risk, not a housekeeping task.

Read next: NHI Ownership and Accountability Guide

What this signals

Microsoft 365 governance will increasingly be judged by evidence, not intent. Regulators and auditors now expect proof that access, ownership and lifecycle controls are working, which means governance teams need observable outcomes rather than policy statements. The programme implication is clear: if you cannot demonstrate control over workspaces, you do not really have control over them.

Identity governance and collaboration governance are converging. In Microsoft 365, the same decisions that govern human access now also shape how apps, agents and workspace assets behave. That convergence means IAM, compliance and collaboration teams need a shared operating model, because siloed ownership creates blind spots at exactly the point where the platform is becoming more interconnected.

Workspace sprawl will become the dominant operational risk in Microsoft 365 programmes. As collaboration and AI features expand, the question shifts from whether users can create content to whether the organisation can still govern it. Practitioners should expect more pressure to prove ownership, recertification and drift control across the full tenant, not just at the file level.

For practitioners

• Inventory every workspace and owner Build a current inventory of Teams, SharePoint sites, OneDrive spaces and Power Platform assets, then identify where ownership is missing or stale. Use that inventory to distinguish managed collaboration spaces from orphaned or abandoned ones.
• Enforce named ownership at creation Require a named business owner before any new workspace, app or site is provisioned. Make ownership part of the creation workflow so responsibility is assigned when the asset is born, not after drift appears.
• Align delegation with least privilege Scope administrative rights to the smallest practical workspace, region or business domain, and keep policy authority central. This prevents the central team from becoming a bottleneck while avoiding blanket admin rights across the tenant.
• Review guest and project-based access on a cadence Set recertification for external users, temporary collaborators and project permissions so access does not survive the work it was granted for. Tie the review cadence to the business context of the workspace, not a generic calendar event.
• Detect configuration drift across tenants Compare current sharing, retention and sensitivity settings against the approved baseline and investigate deviations quickly. Drift detection matters because governance fails gradually, not only at the moment a bad change is made.

Key takeaways

• Microsoft 365 governance fails when ownership, policy and execution are not distributed across the teams that actually create and manage workspaces.
• The most visible failure modes are ownerless workspaces, permission sprawl, stale guests, unmanaged Power Platform assets and configuration drift.
• Practitioners should establish visibility, named ownership and delegated control before trying to automate remediation at scale.

Related NHI Mgmt Group resources: NHI Ownership and Accountability Guide · IAM and IGA Basics · Attack Surface Management Guide · Microsoft 365 Security Guide

Key terms

• Microsoft 365 Governance: Microsoft 365 governance is the operating model that defines how collaboration services are configured, who may use them, how content is retained, and how risk is monitored over time. It combines policy, ownership, lifecycle control and enforcement so the platform stays aligned with business and regulatory needs.
• Shared Accountability: Shared accountability is a governance model where multiple functions own different parts of AI risk instead of leaving responsibility with one team. Engineering, security, risk, legal, and leadership each have distinct duties, but they need common visibility into live system behavior for the model to work in practice.
• Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management in practical terms. It helps practitioners connect identity controls to the broader operating model that modern platforms now demand.