Sensitivity Labels in Microsoft Teams: Setup and Best Practices

Sensitivity labels in Microsoft 365 were originally designed for document and email classification. But over the past few years, Microsoft has extended them to cover Microsoft 365 groups and Teams — which means you can apply a sensitivity label to a team and have that label drive security settings for the entire team workspace, including the underlying SharePoint site.

This is a significant capability for Teams governance. It means that data classification and access control aren't just applied to individual files — they're baked into the team itself. When a team is labelled "Confidential," that label can automatically prevent guests from being added, restrict external sharing in the associated SharePoint site, and control who can access the team from unmanaged devices.

How Sensitivity Labels Work in Teams

Sensitivity labels in Teams work at the Microsoft 365 group level. When a sensitivity label is applied to a team, it's actually applied to the underlying Microsoft 365 group. The label then drives settings for the group and its associated services — SharePoint, Exchange, and Teams.

Labels are created and published in the Microsoft Purview compliance portal. To be available in Teams, a label must be configured with "Group & site" settings enabled, and it must be published to users through a label policy.

Configuring Sensitivity Labels for Teams

The configuration process has two parts: creating labels with the right settings, and publishing them to users.

Step 1: Create or edit a sensitivity label in Microsoft Purview. Navigate to Microsoft Purview compliance portal > Information protection > Sensitivity labels. Create a new label or edit an existing one. In the label configuration, under "Define the scope for this label," ensure "Groups & sites" is selected in addition to "Files & emails."

Step 2: Configure Groups & sites settings. Under the "Groups & sites" scope, you can configure:

• Privacy and external user access settings: Set the team to Public or Private (or let users choose). Critically, control whether team owners can add guests — this is the label's "Azure AD B2B guest" access setting. Setting it to "Prevent team owners from adding guests" is how you use a label to enforce a no-guest policy for certain sensitivity levels.
• External sharing and conditional access: Control whether content in the associated SharePoint site can be shared with external users, and whether access from unmanaged devices is allowed.
• External sharing ceiling: The label can cap SharePoint sharing at "existing guests" or tighter, which stops a private team from being opened up by a site-level change later.
• Default sharing link type: Set the default link to people with existing access when the label is meant for internal project work, so the easy click is not an anonymous link.

Step 3: Publish the label via a label policy. Labels aren't available to users until they're published through a label policy. Create or edit a label policy in Purview > Information protection > Label policies. Add the label, specify which users and groups the policy applies to, and optionally set a default label for groups created by those users.

Designing a Sensitivity Label Taxonomy for Teams

Most organisations need between three and five label tiers for Teams governance. A common taxonomy:

• General / Public: Information that can be shared broadly. External sharing allowed; guests allowed; unmanaged device access allowed.
• Internal: Standard internal business information. External sharing restricted; guests allowed for specific use cases; unmanaged device access limited.
• Confidential: Sensitive business information. No external sharing; no guests; unmanaged device access blocked.
• Highly Confidential: Most sensitive information (legal, financial, executive). No external sharing; no guests; managed devices only; additional access controls.

The label taxonomy should align with your broader information classification policy, not be designed in isolation for Teams. If you already have a document classification scheme, extend it to Teams rather than creating a parallel structure.

Applying Labels: Admin vs User Control

Sensitivity labels on Teams can be applied by team owners during team creation (if labels are published to them), changed by team owners after creation, or applied by administrators. The governance question is whether to give team owners control over their team's label, or to mandate specific labels for specific types of teams.

For organisations with well-understood classification needs (financial services, healthcare, government), it's often better to apply labels through the provisioning process and restrict owner ability to change them. For organisations with less stringent classification requirements, allowing owners to choose and change labels gives flexibility at the cost of consistency.

Monitoring and Reporting

Once labels are deployed, you need visibility into how they're being used. Microsoft Purview provides label activity reports that show which labels are applied to which groups, label distribution across the tenant, and label change events in the audit log. Review these reports periodically to identify teams that are mislabelled (a "General" label on a team containing clearly sensitive content) and to verify that label adoption is progressing as expected.

Labels Applied After the Team Already Has Guests

A sensitivity label changes the rules for a team from the moment it is applied. It does not rewrite history in a way that removes people who are already inside. If a team was public, full of guests, and is then labelled Confidential with guest access disabled, the label stops new guest additions. Guests already on the membership list can remain until someone removes them. Administrators who treat labelling as a cleanup will think the tenant is closed when it is only closed to newcomers.

A law firm with about 700 users labelled every client team in a single weekend after a client asked for evidence of access control. The label was configured to block guests. The report the next Monday still showed guest accounts on 40 client teams, all added in the months before the label existed. The label was correct. The membership was not. The remediation was a scripted removal of guests from labelled teams, with a check that the guest was not also a member of a team whose label still allowed guests.

Order of operations matters for new teams as well. If users can create a team and pick a label afterwards, there is a window with no label. Default the creation path to a label, or block creation for people who will not choose one. A taxonomy with five labels and no default is a taxonomy that produces an unlabelled pile.

Label names should be words the business already uses. A four-level scheme invented by the project team will be clicked at random. Fewer labels, each with a one-sentence description of who may be a member and whether guests are allowed, will be used. The description belongs in the label's tooltip, not only in a slide.

Reporting is the control that keeps the weekend project from rotting. Purview's label distribution for groups and sites shows the unlabelled remainder. Track that remainder as a number with a downward target. A label programme that cannot say what percentage of teams are labelled is not finished, regardless of how careful the taxonomy looked in the design workshop.

Test a label on one team that already has a guest before rolling it out, and write down whether the guest stayed. Changing a label's guest setting later does not revisit every team automatically in the way people hope. Confirm propagation on a sample. Do not stack a label and a conflicting SharePoint sharing setting and expect the stricter one to win without checking the actual site. Give container labels a different conversation from file labels. Teams governance cares first about the container: privacy, guests, and external sharing. If a parent team and a shared channel would need different labels, stop and redesign the channel. A shared channel inherits the host team's label constraints in ways that surprise project leads. Keep the old label name in the change log when you rename one. Reports and tickets will use the old word for months. Unlabelled teams older than the labelling project are a backlog, not an oversight to mention in a footnote. A label that blocks guests should be tested with an owner who is not an administrator. Admin rights can mask the block. Parent and child label names that differ by one adjective will be selected at random. Rename until a tired reader can tell them apart. When a team changes label, record who changed it. Drift by owners is as common as drift by policy. File labels and container labels can share words and mean different things. Say which one a report is counting. If legal asks for encryption on the file and the team only has a container label, those are two projects. Do not report them as one. Sample a labelled team and try to share a file externally. The failure message is part of the evidence. A taxonomy review once a year should delete a label that nobody used. Unused labels teach people to ignore the list.