The cloud suite first introduced sensitivity labels as a way to classify documents and email. In recent years, however, the vendor has extended them to cover cloud groups and Teams as well, so a sensitivity label can now be attached to a team and used to drive security settings across the entire team workspace, all the way down to the underlying the file service site.
In terms of Teams governance, this is a significant capability. Rather than staying something applied only to individual files, classification and access control become part of the team itself. Apply a "Confidential" label to a team, and that label can automatically stop guests being added, restrict external sharing on the connected the file service site, and determine who is able to reach the team from unmanaged devices.
How Sensitivity Labels Work Inside Teams
Within Teams, sensitivity labels operate at the cloud group level. When a label is applied to a team, it is in fact applied to the cloud group underneath it. The label then governs settings for that group and for the services bound to it — the file service, Exchange, and Teams.
Labels are created and published in the compliance portal. In order for a label to surface in Teams, it must be configured with "Group & site" settings switched on and then published to users through a label policy.
How to Configure Sensitivity Labels for Teams
Configuration falls into two stages: defining labels with the correct settings, and publishing those labels to users.
Step 1: Create or modify a sensitivity label in the compliance portal. Navigate to the compliance portal > Information protection > Sensitivity labels. Create a new label or open an existing one. In the label configuration, beneath "Define the scope for this label," verify that "Groups & sites" is ticked together with "Files & emails."
Step 2: Set the Groups & sites options. Inside the "Groups & sites" scope, the following can be configured:
- Privacy and external user access settings: Set the team to Public or Private, or leave the choice to users. Critically, determine whether team owners are permitted to add guests — this is the label's "the cloud platform AD B2B guest" access setting. Selecting "Prevent team owners from adding guests" is how a label enforces a no-guest rule at particular sensitivity levels.
- External sharing and conditional access: Decide whether content held in the linked the file service site can be shared with external people, and whether access from unmanaged devices is allowed.
- External sharing ceiling: The label can hold the file service sharing to "existing guests" or something tighter, so that a later site-level change cannot reopen a private team.
- Default sharing link type: If the label targets internal project work, make the default link "people with existing access," so the convenient click does not produce an anonymous link.
Step 3: Publish the label via a label policy. Labels remain unusable by users until they have been published through a label policy. Create or open a label policy in the compliance portal > Information protection > Label policies. Add the label, specify the users and groups the policy covers, and optionally set a default label for the groups those users create.
Building a Sensitivity Label Taxonomy for Teams
For Teams governance, most organisations settle on three to five label tiers. A typical taxonomy reads like this:
- General / Public: Information that can be distributed widely. External sharing permitted, guests permitted, and access from unmanaged devices permitted.
- Internal: Day-to-day internal business information. External sharing restricted and unmanaged device access limited, with guests allowed only for specific scenarios.
- Confidential: Sensitive business information. Guests and external sharing both prohibited; access from unmanaged devices blocked.
- Highly Confidential: The most sensitive information (executive, financial, legal). No external sharing and no guests, managed devices only, with additional access controls.
Rather than being designed in isolation for Teams, your label taxonomy should follow your wider information classification policy. Where a document classification scheme already exists, extend it into Teams instead of standing up a parallel one.
Setting a default label for new Teams
Within the label policy configuration, you can set a default sensitivity label for new Teams that users create. Assigning a default label — normally "General" or "Internal" — guarantees that every new team carries a classification from its very first day, instead of sitting unclassified until someone applies a label by hand.
Applying Labels: Administrator Control or User Control
Sensitivity labels on Teams can be set by team owners at creation (where labels are published to them), changed by owners afterwards, or applied by administrators. The governance question is whether to give owners control of their team's label, or to mandate specific labels for specific kinds of teams.
Organisations whose classification needs are tightly defined (government, healthcare, financial services) are generally better off applying labels through the provisioning process and restricting owners' ability to change them. Where classification requirements are looser, letting owners pick and change labels buys flexibility at the cost of consistency.
Monitoring and Reporting on Label Use
Once labels are live, you need visibility into how they are genuinely being used. the compliance portal provides label activity reports showing which labels sit on which groups, how labels are distributed across the tenant, and label change events in the audit log. Review these reports periodically to catch mislabelled teams (a "General" label on a team plainly holding sensitive content) and to confirm that adoption is progressing as planned.
Applying a Label to a Team That Already Has Guests
From the instant a sensitivity label lands, it changes a team's rules. What it will not do is rewrite history and expel the people already inside. Consider a team that was public and crowded with guests, then labelled Confidential with guest access disabled: the label stops any further guest additions, but the guests already on the roster remain until someone removes them. Administrators who mistake labelling for a cleanup will conclude the tenant is sealed, when in fact it is only sealed against newcomers.
After a client asked for evidence of access control, a law firm of roughly 700 users labelled every client team across a single weekend. The label was configured to block guests. The report on the following Monday still listed guest accounts on 40 client teams, every one of them added in the months before the label existed. The label was correct; the membership was not. The remedy was a scripted removal of guests from the labelled teams, together with a check that each guest was not also a member of another team whose label still permitted guests.
Ordering matters for new teams as well. Where users can spin up a team and pick a label later, a window exists with no label at all. Either default the creation path to a label, or block creation for anyone who won't choose one. A taxonomy of five labels with no default is a taxonomy that produces a heap of unlabelled teams.
Label names should take their vocabulary from what the business already says. A four-tier scheme invented by the project team gets clicked at random. Fewer labels, each carrying a one-line note on who may belong and whether guests are allowed, are the ones actually used. That note belongs in the label's tooltip, not merely on a slide.
Reporting is the control that keeps the weekend project from decaying. the compliance portal's label distribution for groups and sites exposes the unlabelled remainder. Track that remainder as a figure trending downward. However polished the taxonomy looked in the design workshop, a label programme that cannot state what share of teams are labelled is not finished.
Before rolling a label out, test it on a single team that already has a guest, and record whether that guest remained. Changing a label's guest setting afterwards does not silently reprocess every team as people hope; confirm propagation against a sample. Do not place a label over a conflicting the file service sharing setting and presume the stricter one wins without examining the actual site. Container labels are a separate conversation from file labels; treat them as such. The container comes first for Teams governance: privacy, guests, and external sharing. Where a parent team and a shared channel would call for different labels, stop and reconsider the channel. A shared channel inherits the host team's label constraints in ways that take project leads by surprise. When you rename a label, keep the old name in the change log; tickets and reports will keep using the old word for months. Unlabelled teams that predate the labelling project are a backlog, not a footnote to be brushed aside. Since admin rights can mask the block, a label that blocks guests should be tested with an owner who isn't an administrator. Parent and child label names differing by a single adjective get chosen at random; keep renaming until a tired reader can tell them apart. Log who changed a team's label whenever it changes — owner drift is just as common as policy drift. File labels and container labels can share wording yet mean different things, so state clearly which one a report is counting. If legal wants encryption on the file while the team carries only a container label, those are two projects; do not report them as one. Choose a labelled team and attempt to share a file externally — the failure message forms part of the evidence. Any label nobody used should be retired at the yearly taxonomy review, because unused labels teach people to disregard the entire list.
