Teams starts clean. A handful of teams, clear names, everyone knows where things live. Then a year passes, self-service creation does its thing, and you’re looking at hundreds of teams — duplicates, abandoned projects, three different “Marketing” spaces, and a guest account nobody remembers inviting. That’s Teams sprawl, and it’s the predictable result of deploying Teams without governance.
Governance isn’t about locking Teams down until it’s useless. It’s about putting a few guardrails in place — who can create, how things are named, what’s sensitive, who from outside can join, and when dead teams get retired — so the environment stays navigable and compliant as it grows. The work is mostly upfront policy plus a light ongoing review.
This guide covers the practices that matter in roughly the order you’d implement them, with notes on what each one needs and where the licensing lines fall.
Decide who can create teams
The first lever is creation. Left open, anyone can spin up a team in seconds, which is exactly why sprawl happens. Restricting creation is the highest-impact governance control for most organizations past the early stage.
You don’t do this in the Teams admin center — you restrict Microsoft 365 group creation in Microsoft Entra, allowing a nominated security group to create while blocking everyone else. Pair it with a simple request process so users who genuinely need a team can still get one quickly. The full PowerShell walkthrough is in control who can create teams.
A word of caution: the same setting governs Planner, Outlook groups, SharePoint sites, and Viva Engage. Restricting it stops self-service across all of them, so size your allowed group to cover everyone with a legitimate need, not just Teams users.
Enforce naming and expiration
Once you control who creates teams, control what they’re called and how long they live.
A naming policy adds a consistent prefix or suffix (fixed text or an attribute like department) and blocks reserved or inappropriate words. The payoff is teams that sort and search sensibly instead of a pile of “Project,” “Project 2,” and “Test.” An expiration policy sets a lifetime after which inactive teams are flagged for renewal and deleted if no owner renews — this is what stops abandoned teams accumulating forever.
Both of these require Microsoft Entra ID P1 licensing for the members involved, so confirm your tier before you build around them.
Governance controls and what they need
| Restrict team/group creation | Standard Microsoft Entra — no premium tier |
|---|---|
| Naming policy (prefix/suffix, blocked words) | Microsoft Entra ID P1 or higher |
| Group expiration policy | Microsoft Entra ID P1 or higher |
| Sensitivity labels for teams/groups | Microsoft Purview (and supported Microsoft 365 plan) |
| Access reviews | Microsoft Entra ID Governance / P2 |
Classify teams with sensitivity labels
Not every team holds the same kind of content. A social committee team and a team handling contracts or HR data shouldn’t have the same protection. Sensitivity labels (from Microsoft Purview) let you classify teams and groups and attach behavior to each label — controlling guest access, external sharing, and privacy (public vs private) based on the classification.
Applied to teams and groups, a label can enforce things like “Confidential teams are private and block guests” automatically, so the classification isn’t just a sticker — it changes how the team behaves. This is the cleaner long-term approach than trying to police each team’s settings by hand.
Sensitivity labels depend on Microsoft Purview and a supporting Microsoft 365 plan, and they take some planning to define well. Start with two or three labels people will actually understand rather than a dozen nobody can tell apart.
Control guest and external access
Outside collaboration is one of the biggest governance risks because it’s easy to lose track of who can see what. Teams supports two distinct things people often confuse: guest access (external people added as members of your teams) and external access / federation (chat and calls with other domains).
Decide deliberately:
- Whether guest access is on at all, and which teams allow guests (sensitivity labels can enforce this).
- Which external domains you federate with, if any — allow-list rather than open federation where the risk warrants it.
- A review cadence so guests who no longer need access are removed.
The detailed configuration is in manage guest access in Microsoft Teams. The governance point is that guest access without periodic review is how stale external accounts pile up.
Plan the team lifecycle: archive, then delete
Teams have a natural lifespan. A project finishes, a committee disbands, an event passes. Governance means having a plan for the end of that lifecycle instead of leaving finished teams cluttering everyone’s list.
There are two distinct end states, and choosing the right one matters:
Archive vs delete
| Archive | Team becomes read-only — content, channels, and files stay accessible, no new activity. Reversible: you can reactivate it later. |
|---|---|
| Delete | Team and its Microsoft 365 group are removed, with a recovery window (about 30 days) before it's permanent. |
Archive teams that are finished but worth keeping for reference. Delete teams with no lasting value. The mechanics of both — including how to bring back a team deleted by accident — are in archive a team and restore a deleted team. Expiration policies automate the “delete if abandoned” end; archiving is the deliberate, keep-the-record alternative.
Assign clear ownership
A team with no active owner is a governance dead end: membership can’t be managed, requests stall, and an expiration prompt has nobody to act on it. Require at least two owners per team so there’s always a backup, and set a fallback owner on your expiration policy for groups that end up ownerless.
This is more of a process discipline than a feature toggle, but it’s the one that quietly prevents the most headaches. Ownerless teams are where stale membership and forgotten guests accumulate.
A practical Teams governance baseline
- Creation restricted to an allowed security group, with a request process
- Naming policy enforcing a convention and blocked words (Entra ID P1)
- Expiration policy retiring inactive teams, with a fallback owner (Entra ID P1)
- Sensitivity labels classifying teams and driving privacy/guest behavior
- Guest access scoped deliberately, with periodic reviews
- At least two owners per team; ownerless teams reviewed
- An archive-vs-delete decision for finished teams
Make governance a shared, ongoing job
Governance fails when it’s treated as a one-time IT project. The technical guardrails — creation, labels, lifecycle — belong to IT and security, but the rules they enforce (naming conventions, approval steps, what counts as sensitive) come from the business. A small governance group that meets occasionally keeps policy aligned with how people actually use Teams, and catches the drift before it becomes another cleanup project.
Start small. Restrict creation, add naming and expiration, classify with a couple of labels, and put a review cadence on guests and ownership. You can layer on more later. A baseline that people follow beats an elaborate policy that gets ignored.
Wrapping up
Good Teams governance is a handful of deliberate guardrails: control creation, enforce naming and expiration, classify with sensitivity labels, scope guest access, and plan the lifecycle from archive to delete. Most of it lives at the Microsoft 365 group level, some of it needs Entra ID P1 or Purview licensing, and all of it works better with clear ownership and a light review cadence behind it.
The organizations that stay on top of Teams aren’t the ones with the strictest rules — they’re the ones whose rules are simple enough to actually follow and reviewed often enough to stay relevant.
