Microsoft 365 groups and Teams: governing creation, naming and lifecycle

A group is much more than a member list

Creating a Teams team creates a Microsoft 365 group, which in turn provisions a SharePoint site, a group mailbox, a notebook and a plan. Every group is therefore a new data container, with its own sharing rules, its owners and, potentially, its guests.

Sprawl causes three concrete problems: users no longer know where the authoritative information lives, sensitive data ends up in spaces nobody monitors, and access for former members or guests is never reviewed.

Should creation be restricted?

You can restrict Microsoft 365 group creation to a given security group through the unified group directory settings in Entra ID (the EnableGroupCreation and GroupCreationAllowedGroupId settings, configured with PowerShell). The restriction applies to every app that creates groups: Teams, Outlook, SharePoint, Planner. Administrators with the appropriate roles can still create them.

The choice is not binary. We see three models working:

1. open creation, offset by rigorous naming, expiration and reviews;
2. delegated creation by identified champions in each department;
3. creation on request, via a form and an approval workflow, possibly automated.

An overly restrictive model pushes users towards unmanaged tools or towards catch-all teams used for purposes they were never meant for. The right choice depends on the organisation's maturity and the sensitivity of its data.

Naming policy

The group naming policy automatically adds a prefix or suffix (fixed or based on an attribute such as department or country) and blocks a list of forbidden words. It prevents a user from creating a team called "Executive Board" or "HR" that could mislead colleagues. It requires Entra ID P1 licences for the users concerned; check the current terms.

Keep the convention simple: a readable prefix is often enough. An overly complex policy produces unreadable names and ends up being worked around.

Expiration and ownerless groups

The expiration policy sets a lifetime for groups, for example 180 or 365 days. Groups in use are renewed automatically; for the others, owners receive notifications and must confirm renewal. Without a response, the group is deleted and can be restored for 30 days. Data held by a retention policy stays protected regardless of the deletion.

Ownerless groups are a blind spot: nobody receives expiration notices, nobody manages membership. The Microsoft 365 admin centre offers a policy that invites active members of an orphaned group to become owners. We also recommend requiring at least two owners per group and regularly tracking groups with one owner or none.

Guests, group by group

Tenant guest settings apply to all groups, but you can prevent guests from being added to a specific group, either through a group-specific directory setting or, more simply, with sensitivity labels applied to containers. A "Confidential - internal" label can enforce a private group with no guests and restricted SharePoint sharing. It is the clearest way to vary the rules according to sensitivity.

What an audit checks

• The number of Microsoft 365 groups, how it is growing and the share of inactive groups.
• The creation restriction settings and the allowed group.
• Whether a naming policy exists and the list of blocked words.
• The expiration policy and its lifetime.
• Groups with no owner or a single owner.
• Groups containing guests and the per-group or per-label rules.