QG Professional Services
- Microsoft & Cloud
- Cybersecurity
Microsoft Teams was adopted almost everywhere at speed, and governed almost nowhere. The result, visible in most tenants we assess a year or two in, is sprawl: thousands of teams, most abandoned, many with unknown guests, sensitive files scattered across SharePoint sites nobody owns. Teams is not just a chat app: every team creates a Microsoft 365 Group, a SharePoint site, a document library, a plan and more. Ungoverned, that is a data-governance and security liability accumulating quietly behind the productivity win.
Governance does not mean locking Teams down until people route around it. It means a model that keeps collaboration easy while keeping the estate knowable. Here is that model.
Why ungoverned Teams becomes a problem
- Sprawl and duplication. Anyone can create a team, so people do: duplicates, one-off project teams that outlive the project, near-identical teams because nobody could find the existing one. Each carries a SharePoint site and document library that becomes an unmanaged data store.
- Guest access no one tracks. External collaboration is a Teams strength, but guests added for a project and never removed accumulate into standing external access to internal data: a real exposure, invisible without review. Departed partners retaining access is the common finding.
- Data in unknown places. Sensitive documents land in the SharePoint sites behind teams, outside whatever data-protection controls assume a known structure. You cannot protect what you cannot locate.
- Orphaned ownership. Teams whose owners left, now ownerless, with no one accountable for membership or content: governance vacuums that persist for years.
The governance model
- Creation control: light, not locked. Uncontrolled creation drives sprawl; blocking creation drives shadow IT (people move to unsanctioned tools). The balance most organisations land on: a request or template-based provisioning flow, or delegated creation to trained owners, so new teams are deliberate and start with sensible defaults (naming conventions, an assigned owner, appropriate privacy) rather than raw self-service.
- Lifecycle management with Microsoft 365 Groups expiration. Automatic expiration policies require owners to periodically confirm a team is still needed; unconfirmed teams are archived and eventually removed. This is the single most effective anti-sprawl control: it makes abandonment self-correcting instead of permanent. Note the entitlement: group expiration requires Entra ID P1 for the members of the groups concerned, which every tier from Business Premium upward provides.
- Guest access governance. Define who can invite guests and under what conditions, apply Conditional Access policies to guests, and (critically) run Access Reviews so external access is periodically re-justified or removed. Guests should be a reviewed population, not a growing one.
- Sensitivity labels on teams and groups. Purview sensitivity labels applied at the team/group level set privacy, guest-access and sharing behaviour by classification: a "Confidential" team can automatically forbid guests and block external sharing, enforcing data protection at the container level rather than hoping users classify each file.
- Clear ownership, always. Require at least two owners per team so departure never orphans it, and report on ownerless teams for remediation.
Why this became urgent in the Copilot era
Ungoverned Teams sprawl used to be a slow-burning data-governance problem: sensitive files in SharePoint sites nobody owned, discoverable in principle but rarely in practice. Microsoft 365 Copilot changed the risk profile, because Copilot answers a user's questions using everything that user has permission to reach — including the site they were added to for one project three years ago, and the library with tenant-wide permissions nobody noticed.
Oversharing that was previously latent becomes actively surfaced. The remedies are the governance controls above, plus a specific set worth naming: run oversharing and permission reports before a Copilot rollout rather than after; use sensitivity labels to drive container-level restrictions; and where the estate justifies it, use the SharePoint advanced management capabilities (data access governance reports, restricted access control, and restricted content discovery to fence sensitive sites off from Copilot). The sequencing matters more than the tooling: a Copilot rollout onto an ungoverned estate does not create the exposure, it publishes it.
Governance as an enabler, not a brake
The framing that makes governance succeed: it exists so people can trust and find collaboration spaces, not to restrict them. A well-governed Teams estate is easier to use: you find the right team because duplicates were prevented, you trust a space because its membership is managed, sensitive work has an obvious correct home. Heavy-handed lockdown that pushes people to WhatsApp and personal drives is worse for security than the sprawl it was meant to fix, because it moves the data somewhere you cannot see at all.
Retrofitting governance onto an existing mess
Most organisations need to govern a Teams estate that already sprawled. The sequence: inventory what exists (teams, owners, guests, orphans), archive the obviously dead, establish ownership for the survivors, then apply lifecycle, guest-review and labelling policies going forward. It is a cleanup project followed by a governance model, and the cleanup usually reclaims a startling amount of forgotten external access.
Practical steps
Pull a report of your teams with their owners and guest counts: the orphaned and guest-heavy ones are your priority risks. Enable Microsoft 365 Groups expiration so sprawl becomes self-correcting. Run an access review on external guests this quarter; the results are usually sobering. QG delivers Teams and collaboration governance (provisioning, lifecycle, guest management and sensitivity labelling) as part of Modern Workplace engagements, tuned so collaboration stays easy and the estate stays knowable.