Microsoft Teams governance: the controls are gates, not clean-up

Microsoft Teams governance is the set of controls that decide how teams get created, named, classified, shared outside the organisation, reviewed and eventually retired. Microsoft groups these into around eight capabilities in its Teams governance planning guidance, and they sit across three different products, which is the first thing that catches people out.

Creation restrictions, naming, classification, guest access and expiration are Microsoft Entra ID features, because a team is a Microsoft 365 Group wearing a different interface. Retention and sensitivity labels are Microsoft Purview. Archiving and feature management live in the Teams admin centre itself.

That split matters for a practical reason. The team asking for Teams governance is usually the team that runs Teams, and half of what they need is configured somewhere they don’t have rights to.

It also means the licensing question has several answers rather than one, which is worth settling before anyone builds a plan around a control you can’t actually turn on.

A Microsoft 365 Groups naming policy does two things: it bolts a prefix or suffix onto group names, and it blocks a list of words.

The prefix and suffix can be fixed text or drawn from the creator’s directory attributes, so you can produce something like GRP_Finance_[GroupName] automatically from the department field. Six attributes are supported: Department, Company, Office, StateOrProvince, CountryOrRegion and Title. Custom and extension attributes aren’t, which rules out the one your HR system actually populates properly.

Here’s the part that undoes most people’s expectations. The policy is enforced when a group is created or edited. It is not applied retroactively. Existing teams are untouched at the moment you configure it, and they stay untouched until somebody happens to edit one.

Read that alongside the reason most organisations want a naming policy in the first place, which is that the existing names are a mess, and the gap is obvious. The control addresses the next thousand teams. It has nothing to say about the current four hundred.

Renaming what’s already there is a separate exercise, done in bulk through PowerShell or Graph, and it needs a decision nobody enjoys making: whether a rename that changes what people see in their Teams client is worth the confusion it causes. Sometimes the honest answer is to leave the old names alone, let them age out, and enforce the standard from here.

The blocked-word list takes up to 5,000 comma-separated phrases and matching is case-insensitive. It’s also an exact match on the whole name with no substring searching.

So blocking “Payroll” stops a team called payroll and a team called PAYROLL. It does not stop Payroll-2024, Payroll Team or UK Payroll. If the aim is to keep sensitive words out of names that everyone in the tenancy can see, a short list won’t do it, and a list long enough to catch the variants starts blocking legitimate names.

This is worth knowing before you promise anyone that a word has been prevented rather than discouraged.

Worth knowing

Global Administrators and User Administrators are exempt from the naming policy. They can create groups with blocked words and without the enforced prefix or suffix.

This trips up testing constantly. The administrator who configured the policy creates a test team, watches it appear with the wrong name and no prefix, and concludes the policy hasn’t applied. It has. They’re just exempt from it. Test with an ordinary account or you’ll spend an afternoon debugging something that works.

The group expiration policy is the control that frightens people, because on paper it deletes teams. In practice it deletes almost nothing that anyone still glances at.

The minimum interval is 30 days and you can set a custom value above that. What makes it mild is activity-based auto-renewal: the group renews itself automatically, without the owner doing anything, if there’s been activity in the preceding period. Microsoft counts viewing, editing, downloading, moving, sharing or uploading a file in SharePoint, joining a group or reading, writing or liking a message in Outlook, viewing a post in Viva Engage, and, for Teams, simply visiting a channel.

Visiting a channel. Not posting in it. That’s a very low bar, and it’s why the expiration policy rarely causes the disaster people brace for. It’s also why it clears far less than expected. A team nobody has contributed to in two years still renews itself indefinitely if one person clicks into it looking for an old file.

When a group does expire, it’s deleted a day after the expiration date, following notices at 30 days, 15 days and 1 day. There’s then a 30-day soft-delete window in which it can be restored, and that window is not configurable. Restoring the group brings back its Teams, SharePoint site and Planner content, though Microsoft allows up to 24 hours for everything to come back.

Two constraints shape how you can use it. You get one expiration policy per Entra organisation, so you cannot give the finance directorate a two-year lifecycle and projects a six-month one. And if you scope it to selected groups rather than all groups, you’re capped at 500 groups per policy, which an organisation with real sprawl will exceed.

Container sensitivity labels do considerably more than naming or expiration. Applied to a team, group or site, a label can set privacy to public or private, control whether owners may add guests at all, set the external sharing level, block or limit access from unmanaged devices, require an authentication context such as multi-factor authentication, control whether a private team is discoverable, and restrict who can be invited into shared channels.

That’s the closest thing to real access governance in the list, and it’s the control worth investing in if you only do one properly.

It carries the same limitation as the naming policy though. Labels aren’t applied retroactively. Existing teams have to be labelled manually by an administrator or owner, or in bulk through PowerShell.

A few behaviours are worth knowing before you design around it. Items inside a labelled container don’t inherit the container’s label, so a labelled team doesn’t mean labelled documents. Clearing the external-user setting doesn’t evict guests who already have access, it only affects new ones. Shared channels inherit their parent team’s label automatically and that label can’t then be removed or replaced. And the unmanaged-device setting does nothing unless the matching Conditional Access policy for SharePoint exists, or if the tenant-level setting is already more restrictive than the label.

There’s a timing trap too. A new label needs an hour before it’s usable, 24 hours if it uses the shared-channel controls, and a modified label needs 24 hours. Changes don’t take effect for a user until they re-authenticate. Plenty of people conclude a label is broken when they’ve simply tested it too soon.

This is where Teams governance plans quietly die, so it’s worth establishing early.

The naming policy needs Microsoft Entra ID P1 for every unique user who is a member of at least one Microsoft 365 Group. Not per administrator. Per member. The expiration policy needs Entra ID P1 or P2 for the members of every group the policy applies to, though Microsoft’s wording is that you must possess the licences rather than necessarily assign them.

Entra ID P1 comes with Microsoft 365 Business Premium, E3 and E5. It does not come with Business Basic, Business Standard or E1, and it’s worth checking your own SKU rather than assuming, because this single point decides whether the two controls people reach for first are available at all.

Access reviews and entitlement management, which are the tools for recertifying membership and running proper access requests, need Entra ID P2. That’s a real step up in cost and it’s the reason most mid-sized organisations govern creation well and review membership hardly at all.

Retention policies and Teams archiving need no additional licence, which makes archiving the most underused control in the set. It puts a team into a read-only state without deleting anything, and it’s free.

Locking team creation down to a small group is the most common first move, and Microsoft’s own guidance carries a warning about it that’s easy to skim past: “Limiting group and team creation can slow your users’ productivity, because many Microsoft 365 and Office 365 services require that groups be created for the service to function.”

That’s the real cost. A Microsoft 365 Group isn’t just a team. It’s created behind the scenes when someone makes a Planner plan, a Viva Engage community, a Power BI workspace or a SharePoint team site. Restrict group creation and you restrict all of it, often without realising which workflows you’ve just broken.

If you do restrict it, the request process has to be genuinely quick. A form that takes three days to turn around teaches people to hold meetings in chats and store documents in OneDrive, which is a worse governance outcome than a slightly untidy list of teams. We’ve seen the same dynamic in Power Platform, where over-restriction produces workarounds rather than compliance, and it’s one of the patterns behind why Power Platform governance fails as organisations grow.

The alternative worth considering is leaving creation open and investing in the lifecycle end instead: labels applied at creation, expiration running, ownership enforced, archiving used routinely. Untidy but alive beats tidy but circumvented.

Nothing in the control set, which is the point of this post.

Reducing what already exists is a clean-up project with its own scope, and it runs roughly like this. Inventory what you have, with owner, last activity date and membership count against every team. Identify the ones with no owner at all, which is the category that causes the most trouble later. Decide per team whether it’s archived, merged, renamed or left alone. Then execute it in bulk, and only then turn the gates on so the position you’ve reached holds.

Doing it in that order matters. Turn the controls on first and you’ve frozen the mess in place with a tidy fence around it. Run the clean-up first without the controls and you’ll be doing it again in a year.

Most of the work is the decisions rather than the configuration. Inventory takes hours with PowerShell or the admin centre. Agreeing who owns 400 teams takes considerably longer, because the answer for a good number of them is that nobody wants to.

If you’re on Business Basic, Business Standard or E1, the naming and expiration policies aren’t available to you without buying Entra ID P1, and the honest answer may be that the sprawl doesn’t yet justify the licence uplift. Archiving and retention are free and will get you a reasonable distance.

If you have fewer than 50 teams and they’re all owned and active, you don’t have a governance problem, you have a naming preference. Write a standard down, apply it going forward, and spend the effort elsewhere.

And if nobody has agreed who is accountable for reviewing teams, don’t start with the technical controls. Policies with no owner become a configuration nobody remembers making, and in two years someone will ask why the tenancy deletes things and nobody will know.