How To Use Microsoft Purview Container Sensitivity Labels To Reduce Oversharing And Strengthen Microsoft 365 Copilot Governance

Most Microsoft 365 oversharing starts before a single file is uploaded.

It begins when Microsoft Teams, SharePoint sites, and Microsoft 365 Groups are created using generic tenant-wide defaults.

In an AI-enabled world, those overly permissive defaults become significantly more dangerous because Microsoft 365 Copilot operates within existing permissions.

This is why I recently delivered a Microsoft Security Community Purview Lightning Talk titled:

“The Purview Hack No One Talks About: Container Sensitivity Labels That Fix Oversharing Fast”

The session focused on a simple but highly effective governance concept:

Instead of trying to remediate oversharing after it happens, organisations should apply the correct collaboration controls automatically at the point where Teams, Groups, and SharePoint sites are created.

Microsoft Purview container sensitivity labels make this possible by enforcing:

• privacy settings
• guest access controls
• sharing restrictions
• Conditional Access integration

consistently across Microsoft 365 collaboration workspaces.

By the end of this guide, you will understand how to:

• ✅ Reduce oversharing in Microsoft 365
• ✅ Apply risk-based controls to Microsoft Teams and SharePoint sites
• ✅ Govern guest access and external sharing consistently
• ✅ Improve Microsoft 365 Copilot governance and AI readiness
• ✅ Standardise collaboration governance at scale

Key Takeaways

• Microsoft 365 Copilot surfaces content users can already access
• Oversharing often begins at workspace creation
• Container sensitivity labels govern collaboration risk
• Teams, Groups, and SharePoint sites can enforce different controls
• Guest access and external sharing should be risk-based
• Container labels complement item-level sensitivity labels

Why Oversharing Is A Growing Microsoft 365 Copilot Risk

Oversharing in Microsoft 365 often starts before any data is added, at the point where collaboration spaces are created.

As I explained during the Purview Lightning Talk:

“The real problem is not whether users create workspaces themselves or IT does it for them. The problem is that very different collaboration scenarios are treated the same way.”

In many organisations, users can create Microsoft Teams, Microsoft 365 Groups, and SharePoint sites themselves using tenant-wide defaults.

Those defaults are often:

• generic
• overly permissive
• not aligned to business risk

Other organisations take the opposite approach and restrict workspace creation entirely, forcing users to raise requests to IT.

However, both approaches often create the same underlying governance problem.

Access controls still rely on:

• global defaults
• manual judgement
• inconsistent administrator decisions

As I noted during the session:

“The risk has not been removed. It has just been shifted.”

Different Collaboration Scenarios Require Different Controls

Most Microsoft 365 environments apply the same collaboration defaults across very different business scenarios.

However, collaboration risk varies significantly depending on the workspace purpose, users, and data sensitivity.

However, collaboration risk varies significantly depending on:

• workspace purpose
• business sensitivity
• external access requirements
• data exposure risk

Why This Matters For Microsoft 365 Copilot

Microsoft 365 Copilot does not create new access permissions.

It surfaces content users can already access across:

• Microsoft Teams
• SharePoint Online
• OneDrive
• Microsoft 365 Groups

If your environment contains:

• overshared Teams
• broadly accessible SharePoint sites
• excessive external sharing
• inconsistent guest access controls

then Copilot becomes a force multiplier for discoverability.

That is why reducing oversharing should be considered one of the foundational steps in any Microsoft 365 Copilot governance strategy.

Why Most Organisations Get This Wrong

Most organisations still try to fix oversharing after content has already been exposed instead of preventing risky collaboration configurations from being created in the first place.

Many organisations assume governance problems are solved by:

• restricting who can create Teams
• disabling guest access
• forcing users through IT approval processes

In practice, these approaches often create friction without improving consistency.

As discussed during the Purview Lightning Talk:

“Different creation models put the same underlying issue. Access controls are still driven by defaults and not risk.”

Whether workspaces are created by:

• end users
• IT administrators
• provisioning workflows

the same problem frequently remains:

Very different collaboration scenarios inherit the same controls.

An organisation-wide Team, a partner collaboration site, and a highly confidential project workspace often receive identical sharing and guest access settings despite having completely different risk profiles.

The objective should not be to slow collaboration down or force users through more governance processes.

The objective should be to apply the correct controls automatically based on collaboration risk.

This is where Microsoft Purview container sensitivity labels become one of the most effective and underused Microsoft 365 governance controls available.

Instead of relying on:

• tenant-wide defaults
• user judgement
• inconsistent administrator decisions
• manual oversight

container sensitivity labels allow organisations to make every Microsoft Team, Microsoft 365 Group, and SharePoint site secure by default.

What Are Microsoft Purview Container Sensitivity Labels?

Microsoft Purview sensitivity labels can protect both:

• Items such as Office files and emails
• Containers such as:
  • Microsoft Teams
  • Microsoft 365 Groups
  • SharePoint sites

When applied to a container, the label enforces collaboration and access controls across the entire workspace.

This includes settings such as:

• Privacy
• Guest access
• External sharing
• Unmanaged device access
• Conditional Access integration

Important: Container Labels Do Not Protect Files

Container sensitivity labels do not apply protection directly to files stored within the workspace.

Files inside a labelled Team or SharePoint site do not automatically inherit the container label.

If you require:

• Encryption
• Headers or footers
• Watermarks
• Auto-labelling

you must use item-level sensitivity labels.

The Simplest Way To Understand The Difference

• 🔐 Container labels control access to the workspace
• 📄 Item labels protect the content inside the workspace

Both are required for a complete Microsoft 365 data protection strategy.

Container vs Item Labels: Why Both are Needed

Sensitivity labels operate at two different layers within Microsoft 365:

• Containers
• Items

These controls are complementary, not interchangeable.

What This Means Operationally

Container labels define:

• Who can access the workspace
• How collaboration works
• Whether external sharing is allowed

Item labels define:

• How individual files and emails are protected
• Whether encryption is applied
• Whether content markings are enforced

Together, they create a layered governance and protection model.

How Container Sensitivity Labels Reduce Oversharing

The easiest way to understand container sensitivity labels is to think of them as the translation layer between governance decisions and technical enforcement.

As I explained during the session:

“Container sensitivity labels sit in the middle as the translation layer. They turn risk and policy decisions into enforced controls.”

At the top are governance and risk decisions:

• What collaboration types are allowed?
• Where should guest access be permitted?
• Which workspaces require stronger controls?
• Where should external sharing be restricted?

Container sensitivity labels then apply those decisions consistently across:

• Microsoft Teams
• Microsoft 365 Groups
• SharePoint Online

regardless of whether the workspace is created by:

• end users
• IT administrators
• automated provisioning processes

This creates scalable Microsoft 365 governance without relying on:

• support tickets
• manual approvals
• inconsistent administrator decisions
• user security choices

Risk-Based Governance Model

The following model shows how container sensitivity labels translate business and security requirements into consistently enforced collaboration controls across Microsoft Teams, Microsoft 365 Groups, and SharePoint sites.

What Controls Can Container Labels Enforce?

Container sensitivity labels can enforce a wide range of collaboration and access controls across Teams, Groups, and SharePoint sites.

These include:

• Privacy settings
• Guest access controls
• SharePoint external sharing controls
• Access restrictions for unmanaged devices
• Authentication contexts for Conditional Access integration
• Default sharing link behaviour
• Site sharing restrictions

The Governance Model Behind Container Labels

The easiest way to explain container sensitivity labels is to think of them as the translation layer between governance decisions and technical enforcement.

As I described in the Lightning Talk:

“Container sensitivity labels sit in the middle as the translation layer. They turn risk and policy decisions into enforced controls.”

At the top are business and governance decisions:

• What collaboration types are allowed?
• Where is external sharing appropriate?
• Which workspaces require stronger controls?

Container sensitivity labels then enforce those decisions consistently across:

• Microsoft Teams
• Microsoft 365 Groups
• SharePoint sites

regardless of whether the workspace is created by a user or provisioned by IT.

This creates scalable governance without relying on:

• manual judgement
• support tickets
• inconsistent administrator decisions
• end-user security choices

Recommended Container Label Model

Keep your container sensitivity labels simple and aligned to collaboration risk.

These labels do not need to mirror your file and email classification taxonomy.

As I explained during the demo:

“These are not data classification labels. They represent collaboration risk.”

The purpose of container labels is to govern:

• workspace access
• guest collaboration
• sharing behaviour
• external access

rather than classify documents.

Example label model for Teams, Groups and SharePoint

How to interpret this model

• Public / Internal
  • Low-risk collaboration
  • No external access
  • Minimal restrictions
• External
  • Controlled external collaboration
  • Guests allowed, but with restrictions
  • Reduced risk via web-only unmanaged access
• Highly Confidential
  • High-risk or sensitive data
  • No external access
  • Strong access controls enforced

Implementation

Step 1: Enable Container Labelling

Before you can create sensitivity labels for Teams, Groups and SharePoint sites, container labelling must be enabled.

This is a one-time configuration required to activate the Groups and sites settings in Microsoft Purview.

When Is This Required?

If you see that the Groups and sites option is greyed out when creating a sensitivity label:

👉 Container labelling has not been enabled yet

How Container Labelling Is Enabled

This step must be completed by a Global Administrator and involves:

• Enabling container sensitivity labels using Microsoft Graph PowerShell
• Synchronising labels using Exchange Online PowerShell

Once this process is complete, container-based settings become available in Microsoft Purview.

What Happens After Enablement?

Once enabled:

• ✅ The Groups and sites option becomes available in the label wizard
• ✅ You can configure privacy, guest access and sharing controls
• ✅ Labels can be applied to:
  • Microsoft Teams
  • Microsoft 365 Groups
  • SharePoint sites

For setup instructions, see: Use sensitivity labels with Microsoft Teams, Microsoft 365 Groups, and SharePoint sites | Microsoft Learn

Step 2: Create The Labels

Once container labelling is enabled, the next step is to create sensitivity labels configured for Groups and sites.

⚠️ Important: If the Groups and sites option is still greyed out then Container labelling has not been enabled (return to Step 1)

Create A Label

In the Microsoft Purview portal:

1. Go to Information Protection
2. Select Labels
3. Click Create label
4. Define:
   • Name
   • Description
   • Tooltip:

Select The Correct Scope

When prompted to define the scope:

Select Groups and sites

This enables configuration of:

• Access controls
• Sharing settings
• Privacy settings

for Teams, Microsoft 365 Groups, and SharePoint sites.

Step 3: Configure The Groups And Sites Settings

Configure Privacy Settings

Configure Privacy Settings

• Public: Anyone in the organisation can discover and join the workspace.
• Private: Only owners can add members. Non-members cannot access or discover the workspace contents.
• None: Users choose whether the workspace is Public or Private during creation.

Configure External User Access

• Guest Access Disabled: Guests cannot join the Team, Group, or SharePoint site.
• Guest Access Enabled: Guests can be added to the workspace where collaboration requires it.

Configure SharePoint Sharing Settings

• Only People In Your Organisation: External sharing is blocked.
• Existing Guests: Sharing is limited to guests already present in Microsoft Entra B2B.
• New And Existing Guests: Users can invite and collaborate with new external guests.
• Anyone: Users can create anonymous sharing links that do not require authentication or guest accounts.

Configure Unmanaged Device Access

You can also restrict how labelled SharePoint sites are accessed from unmanaged devices. This integrates with Microsoft Entra Conditional Access policies.

The Operational Benefits Of Container Sensitivity Labels

Container sensitivity labels are not just security controls.

They also simplify governance operations by:

• reducing reliance on manual approvals
• standardising collaboration controls
• improving consistency across Microsoft Teams and SharePoint sites
• enabling scalable Microsoft 365 governance

Consistent Governance Without User Security Decisions

One of the biggest advantages of container sensitivity labels is that users no longer need to make complex security decisions themselves.

As I explained during the demo:

“Users are not asked to make security decisions. Those decisions have already been made centrally and enforced automatically.”

When users create a Team, Group, or SharePoint site, they simply select the collaboration type that matches their business scenario.

The appropriate governance controls are then applied automatically and consistently every time.

This significantly reduces:

• accidental oversharing
• inconsistent sharing behaviour
• reliance on user training
• manual governance overhead

Step 4: Publish The Labels

Once configured, publish the labels using a label policy.

This makes the labels available for users and administrators to apply to:

• SharePoint sites
• Microsoft Teams
• Microsoft 365 Groups

PowerShell-Only Controls

While most container label settings can be configured directly within Microsoft Purview, several important SharePoint governance controls currently require PowerShell.

These include:

• Default sharing link behaviour
• Default sharing permissions
• Site sharing restrictions

Microsoft documents these settings using Set-Label and AdvancedSettings.

Example Configurations

# Default sharing scope: Specific people
Set-Label -Identity <LabelGuid> -AdvancedSettings @{DefaultSharingScope="SpecificPeople"}

# Default share link permission: Edit
Set-Label -Identity <LabelGuid> -AdvancedSettings @{DefaultShareLinkPermission="Edit"}

# Site sharing behaviour: only owners can share (example)
Set-Label -Identity <LabelGuid> -AdvancedSettings @{MembersCanShare="MemberShareNone"}

Microsoft Reference

• Set-Label (ExchangePowerShell) | Microsoft Learn
• Use sensitivity labels to protect collaborative workspaces (groups and sites) | Microsoft Learn

Container Labels Can Also Remediate Existing Oversharing

Container sensitivity labels are not only preventative controls for newly created workspaces.

They can also be applied to existing:

• Microsoft Teams
• Microsoft 365 Groups
• SharePoint sites

to standardise governance across legacy collaboration environments.

As I explained during the session:

“This approach is not just preventative. Container sensitivity labels can be bulk applied to existing Teams, Groups and SharePoint sites.”

For many organisations, this makes container sensitivity labels one of the fastest ways to reduce Microsoft 365 oversharing risk at scale without requiring large migration projects.

If you already have hundreds or thousands of existing collaboration workspaces, read my detailed guide on how to bulk analyse and apply sensitivity labels to existing Microsoft 365 Groups, Teams, and SharePoint sites using PowerShell and PnP PowerShell:

https://nikkichapple.com/how-do-i-add-sensitivity-labels-to-your-existing-groups-teams-and-sites/

That guide covers:

• analysing existing sharing and guest access configurations
• identifying oversharing risks
• mapping labels based on collaboration risk
• bulk applying container sensitivity labels at scale

Watch the Purview Lightning Talk (Microsoft Security Community) 📺

This blog is based on my Microsoft Security Community Purview Lightning Talk focused on reducing oversharing using Microsoft Purview container sensitivity labels.

The session covers:

• live demonstrations
• the governance model
• collaboration risk
• practical configuration guidance

Watch the setup in action

You can also watch my detailed walk-through on enabling and configuring sensitivity labels for Teams, SharePoint, and Microsoft 365 Groups on Empowering.Cloud.

Enabling and creating sensitivity labels for Microsoft Teams, SharePoint and Microsoft 365 Groups

Empowering Cloud video on Sensitivity Labels for Groups, Teams and Sites.

Key Considerations And Limitations

Keep the following considerations in mind during deployment:

• Container labels govern the workspace, not the files stored inside it
• Files do not automatically inherit the container label
• Unmanaged device controls rely on Conditional Access integration
• Authentication contexts require Microsoft Entra Conditional Access configuration
• Governance responsibilities and ownership models should still be clearly defined

Container sensitivity labels are highly effective, but they work best as part of a broader Microsoft 365 governance and data protection strategy.

Why This Matters

Tenant-wide defaults are generic. Collaboration is not.

In many organisations, oversharing is not caused by malicious behaviour. It happens because Microsoft Teams, SharePoint sites, and Microsoft 365 Groups inherit overly broad default settings or rely on inconsistent manual decisions.

The result is that:

• external collaboration may become too permissive
• sensitive projects may inherit weak controls
• guest access is applied inconsistently
• sharing behaviour varies between workspaces
• governance depends on human judgement instead of policy

This becomes significantly more important in the era of Microsoft 365 Copilot and generative AI.

Microsoft states that Copilot operates within existing permissions. That means overshared Teams, SharePoint sites, and Microsoft 365 Groups can become easier to discover, search, and surface through AI-powered experiences.

As discussed during the Purview Lightning Talk:

“Most organisations fix oversharing after the fact. Container sensitivity labels allow you to prevent it from the start.”

Microsoft Purview container sensitivity labels provide a scalable way to align collaboration controls with business risk while improving:

• Microsoft 365 governance
• Copilot readiness
• guest access governance
• external sharing controls
• risk-based collaboration
• secure-by-default workspaces

As I concluded during the session:

“Container sensitivity labels let you govern collaboration risk consistently without slowing people down or relying on manual judgement.”

The goal is not to make collaboration harder.

The goal is to make every Microsoft Team, Microsoft 365 Group, and SharePoint site secure by default based on the collaboration scenario and business risk.

If you are beginning your Microsoft 365 Copilot governance journey, container sensitivity labels are one of the highest-impact controls you can implement early.

Recommended Next Steps

• ✅ Review how Teams, Groups, and SharePoint sites are created in your tenant
• ✅ Identify where collaboration defaults are overly permissive
• ✅ Define a simple risk-based container label model
• ✅ Standardise collaboration governance using Microsoft Purview sensitivity labels
• ✅ Review existing collaboration workspaces for oversharing risks

And most importantly:

“Ask whether access controls are applied consistently or just differently.”

As Microsoft 365 Copilot adoption accelerates, organisations that reduce oversharing early will be significantly better positioned to scale AI safely, confidently, and securely.

Frequently Asked Questions (FAQ)

Microsoft References

Use sensitivity labels with Microsoft Teams, Microsoft 365 Groups, and SharePoint sites – Microsoft Purview (compliance) | Microsoft Learn

Assign sensitivity labels to groups – Azure AD – Microsoft Entra | Microsoft Learn

Use sensitivity labels to configure the default sharing link type for sites and documents in SharePoint and OneDrive