Introduction: Oversharing Does Not Start With Files
How to apply sensitivity labels at scale to existing Microsoft 365 Groups, Microsoft Teams and SharePoint sites is one of the most common follow-up questions I receive when discussing container sensitivity labels.
If your environment only contains a small number of workspaces, applying labels manually is manageable.
However, most organisations operate at scale. Hundreds or even thousands of Microsoft 365 Groups, Microsoft Teams and SharePoint sites already exist.
This is where governance becomes inconsistent and risky.
In this post, I show how to:
✅ Analyse your existing environment
✅ Identify oversharing risk
✅ Apply container sensitivity labels at scale using PowerShell
The goal is not just automation.
It is to apply consistent, risk-based governance and reduce oversharing in Microsoft 365 and Copilot environments.
This approach ensures you can apply container sensitivity labels at scale across existing Microsoft 365 environments in a consistent and controlled way.
This Article Is Part of a Container Sensitivity Labels Series
- Container Sensitivity Labels: The Purview “Hack” That Fixes Copilot Oversharing Fast explores the governance challenge and why container labels are critical in a Copilot-enabled environment.
- How to Configure Container Sensitivity Labels in Microsoft Purview (Step-by-Step) walks through the end-to-end configuration process.
Table of Contents
Step 1: Define Your Sensitivity Label Policy
The first step is to define how container sensitivity labels will be used across your organisation.
These labels control:
- Privacy settings
- Guest access
- External sharing
- Access conditions
👉 They do not classify content. They govern collaboration.
✅ Keep the model simple.
Start with:
- Internal
- External
Expand only if required.
Step 2: Create Container Sensitivity Labels in Microsoft Purview
Once your strategy is defined, create your labels in:
Microsoft Purview Admin Center → Information Protection
⚠️ If labels for Microsoft 365 Groups, Microsoft Teams and SharePoint sites are not enabled, you must enable this first.
Follow my detailed instructions on How to Configure Container Sensitivity Labels in Microsoft Purview (Step-by-Step), which walks through the end-to-end configuration process.
Key Recommendation
✅ Keep container labels separate from content labels
They serve different purposes:
- Item labels → file and email protection
- Container labels → workspace governance
Step 3: Analyse Existing Microsoft 365 Groups, Microsoft Teams and SharePoint sites
Before applying container sensitivity labels, you must understand your current environment to define the rules needed to apply container sensitivity labels at scale.
👉 This is one of the most important steps.
At scale, it is not enough to review individual workspaces. You need a tenant-wide view of access, sharing and data exposure.
Using SharePoint Advanced Management insights
If you have at least one Microsoft 365 Copilot licence, you can use SharePoint Advanced Management data access governance snapshot reports to accelerate your analysis.
Site permissions across your organisation snapshot report
Use the Site permissions across your organisation report to identify:
- broad permission assignments such as Everyone except external users
- sites with guest access enabled
- external sharing configurations
- use of sharing links
- sites with unique permissions
👉 These insights reflect the state of permissions at the time of report generation and provide a centralised, tenant-wide view without requiring scripting.
Sensitivity labels applied to files snapshot report
If you are already using sensitivity labels for files and emails, this adds an important dimension to your analysis.
Review:
- which sites contain sensitive files
- how those files are labelled
- which protection policies apply
👉 This helps you understand where sensitive data is stored.
⚠️ A common gap is that files are labelled and protected, but the workspace remains overly permissive.
👉 This creates a mismatch between content protection and access control.
Using Microsoft Purview DSPM Data Risk Assessments
Microsoft Purview Data Security Posture Management (DSPM) adds a risk-based layer to your analysis.
Assess oversharing of sensitive data
The default DSPM assessment evaluates:
- the top 100 SharePoint sites
- based on user activity and access frequency
- using data collected over the last 30 days
👉 This highlights:
- highly accessed sites
- potential exposure of sensitive data
- areas where oversharing risk is most significant
Custom DSPM assessments (preview)
Custom DSPM assessments allow you to focus on:
- specific SharePoint sites or locations
- targeted users or groups
- high-risk collaboration scenarios
👉 These assessments help identify:
- where sensitive data is broadly accessible
- which users may have excessive access
- where data exposure risk is highest
Using PowerShell for detailed analysis
Use PnP PowerShell to extract data across all Microsoft 365 Groups, Microsoft Teams and SharePoint sites.
This allows you to capture more granular information than the out-of-the-box reports, for example:
- custom metadata stored in the site property bag
- detailed sharing configuration
- ownership and access patterns
👉 This provides a technical foundation for understanding your collaboration landscape.
Bringing the analysis together
By combining these approaches, you can build a complete view of your environment:
- PowerShell → detailed configuration and access data
- SharePoint Advanced Management → tenant-wide visibility
- DSPM assessments → sensitive data exposure and risk
- Purview labels → content sensitivity and classification
👉 This provides a holistic view of your Microsoft 365 environment.
👉 This shifts your approach from configuration review to risk-based governance.
Outcome of the analysis phase
The goal of this step is to:
✅ Identify oversharing risk
✅ Understand external collaboration patterns
✅ Detect inconsistencies and configuration drift
✅ Prepare for risk-based label application
Recommended output
- Import the CSV files into a Power BI model
- Use Copilot to analyse and reason over the data
Without this layered approach, organisations risk focusing on configuration rather than actual data exposure.
Step 4: Identify Risk and Define Label Mapping
This is the most critical step in the process.
👉 You are translating analysis into governance decisions.
At this stage, the goal is not just to review data, but to apply consistent, risk-based controls across Microsoft 365 Groups, Microsoft Teams and SharePoint sites.
From analysis to risk classification
The output from Step 3 provides multiple signals:
- access and permissions (SharePoint Advanced Management)
- sensitive data exposure (Purview labels and DSPM)
- usage patterns (DSPM activity-based insights)
- configuration and ownership (PowerShell)
👉 These signals must now be translated into clear risk categories.
👉 The goal is to move from generic defaults to risk-driven collaboration control.
Risk-Based Label Decision Model
The following model helps map collaboration scenarios to label decisions:
| Risk Scenario | Characteristics | Recommended Action |
|---|---|---|
| ✅ Low Risk | No guests No external sharing | Apply Internal label. This should be your default label |
| ✅ Controlled Collaboration | Guests present External sharing required | Recommend External label. Review with owner. |
| ⚠️ High Risk | Guests present External sharing enabled but not required | Apply Internal label ⚠️ Remove external user |
👉 This model ensures that access aligns with actual business need, not default settings.
👉 Keep the model simple and aligned to business requirements.
Focus on prioritisation
At scale, it is not practical to remediate everything at once.
👉 You need to prioritise where to act first.
Focus on:
- High-risk workspaces
- Overexposed workspaces
- Sites with external users or broad permissions
- Workspaces containing sensitive or regulated data
- High-usage collaboration sites
- Map each workspace to a defined risk category based on your model
👉 Without prioritisation, large-scale remediation becomes impractical and inconsistent.
Common issues identified during mapping
During this phase, you will typically uncover:
- Inconsistent naming conventions
- Missing or incorrect ownership
- Excessive sharing permissions
- Legacy configuration drift
- Inactive and dormant workspaces
👉 These issues should be addressed alongside label application.
Governance outcome
The output of this step is a clear, actionable mapping between:
- collaboration scenarios
- risk levels
- container sensitivity labels
👉 This analysis enables you to confidently apply container sensitivity labels at scale based on risk.
✅ labels are applied consistently
✅ access is governed based on risk
✅ oversharing is reduced at the source
Step 5: Apply Container Sensitivity Labels at Scale
This is where you operationalise your approach to apply container sensitivity labels at scale using automation.
Once mapping is defined, labels can be applied programmatically.
Key requirement
⚠️The sensitivity label GUID must be used when programmatically updating the sites. You cannot use the name or display name.
Use Security and Compliance PowerShell to get the GUIDs for the container sensitivity labels.
Get-Label | Where-Object {$_.ContentType -EQ 'Site, UnifiedGroup'} | Format-Table DisplayName, Guid
Bulk application process
- Create CSV with:
- URL
- LabelGuid
- Use PowerShell to:
- Import CSV
- Loop through each site
- Apply label
The script uses PnP PowerShell, imports the CSV, loops through each row, and adds the sensitivity label to each site URL. If the site is a Microsoft 365 group-connected site, the label is also applied to the Microsoft 365 Group/ Microsoft Teams. Finally, a CSV file is created to summarise the updates.
⬇️Download the PowerShell script from my GitHub Public/Bulk_Add_Container_Sensitivity_Labels.ps1 at main · nikki-c/Public (github.com)
Important behaviour
⚠️ Applying a label does NOT remove existing guests
You must:
✅ Remove users first
✅ Then apply restrictive label
Validation
✅ Re-run analysis script
Confirm:
- labels applied
- sharing controls updated
Managing Container Sensitivity Labels
Admins can manage labels from:
- SharePoint Admin Centre
- Microsoft Teams Admin Centre
- Microsoft 365 Admin Center
- Entra Admin Center
✅ Important consideration
The initial container sensitivity label applied to a Group, Team or SharePoint site may not always be correct.
Collaboration requirements evolve over time, and a label that was appropriate at creation may no longer reflect the current risk.
Group, Team and site owners, as well as administrators, can change container sensitivity labels.
👉 This means governance is not a one-time activity.
Monitoring label changes
Changes to container sensitivity labels are captured in the Microsoft 365 Unified Audit Log.
This provides visibility into:
- who changed the label
- when the change occurred
- which workspace was affected
👉 This allows you to audit and investigate label changes as part of your governance and compliance processes.
Controlling which labels users can apply
You can control which container sensitivity labels are available to different users by using multiple sensitivity label publishing policies.
This enables a risk-based approach:
- ✅ Lower-risk labels such as Internal can be published to all users
- ⚠️ Higher-risk labels such as External or Confidential can be restricted to a smaller group of users or administrators
👉 This ensures that:
- users cannot select inappropriate labels
- higher-risk collaboration scenarios are controlled
- governance decisions are applied consistently
Governance takeaway
Container sensitivity labels are not only about applying controls.
They require:
- alignment with business risk
- ongoing monitoring
- controlled usage
Conclusion
Applying container sensitivity labels at scale is a key step in reducing oversharing across Microsoft 365 environments.
It allows organisations to move from:
❌ inconsistent, manual decisions to ✅ consistent, risk-based governance
At scale.
In a Copilot-enabled environment:
- 👉 Access equals visibility
- 👉 Visibility equals risk
Container sensitivity labels address this at the source.
✅ They control collaboration
✅ They standardise access
✅ They reduce exposure
Frequently Asked Questions
What are Microsoft Purview container sensitivity labels?
Container sensitivity labels in Microsoft Purview are used to control how Microsoft Teams, Microsoft 365 Groups and SharePoint sites are configured. They define privacy, access and sharing settings at the workspace level, ensuring governance is applied consistently.
Why are container sensitivity labels important for Microsoft 365 Copilot?
Container sensitivity labels are critical for Microsoft 365 Copilot because Copilot operates within existing permissions. Labels ensure those permissions are governed from the start, reducing oversharing and controlling what Copilot can surface.
Do container sensitivity labels protect files and emails?
No. Container sensitivity labels do not protect files or emails. They govern the workspace itself, while item-level sensitivity labels are required to classify and protect files, emails and other content.
How do container sensitivity labels reduce oversharing risk?
Container sensitivity labels reduce oversharing by enforcing access and sharing controls when a workspace is created. This prevents overly permissive configurations before data becomes discoverable across Microsoft 365 and Copilot.
Can you apply sensitivity labels to existing Microsoft 365 Groups, Microsoft Teams and SharePoint sites?
Yes. Sensitivity labels can be applied to existing Microsoft 365 Groups, Microsoft Teams and SharePoint sites using PowerShell and Microsoft Purview. This allows organisations to remediate oversharing risk and standardise governance at scale.
Do sensitivity labels remove existing guest access?
No. Applying a sensitivity label does not remove existing guests. If a label restricts external access, guest users must be removed separately for the control to take full effect.
Do I need to restrict who can create Microsoft 365 Groups, Microsoft Teams and SharePoint sites to control oversharing?
No. Restricting who can create Microsoft 365 Groups, Microsoft Teams and SharePoint sites may reduce volume but does not ensure consistent access control. Container sensitivity labels enforce governance automatically, regardless of who creates the workspace.
Where should I start when applying container sensitivity labels at scale?
Start by analysing your existing environment to identify external access, sharing settings and risk levels. Then define a simple, risk-based labelling model and apply labels to high-risk workspaces first.
Final Thoughts
Container sensitivity labels are not just a configuration feature.
👉 They are a governance control layer
And in the Copilot era:
✅ Governance is no longer optional
✅ It must be applied by design
Microsoft Reference
Connect to Security & Compliance PowerShell | Microsoft Learn
https://pnp.github.io/powershell
⚠️Group, team and site owners can change the container sensitivity labels, so you may want to keep track and revert to the original label. Read my colleague Alexander Holmeset’s blog post on Monitor and reset to the original Sensitivity Label if changed for your SharePoint site or M365 Group/Team! | A blog about automation and technologies in the cloud (alexholmeset.blog)