Join our MVP, Nikki Chapple as she delivers this lightning talk for the Microsoft Security Community YouTube channel with over 38,000 followers!
Most organizations fix oversharing after the fact—but what if you could prevent it from the start? This lightning talk shows how container sensitivity labels enforce the right sharing and collaboration controls automatically—so every Group, Team, and SharePoint site is secure by default.
Full Transcript
Why Oversharing Starts Before Data Exists (00:00:02 – 00:01:37)
Nikki Chapple:
Hello, my name is Nikki Chapple, a Microsoft 365 and Purview MVP and Principal Cloud Architect.
I’m here today to talk about the Purview hack no one talks about: container sensitivity labels that fix oversharing fast.
Oversharing in Microsoft 365 usually starts before any data is added—at the point where collaboration spaces are created.
In some organizations, users can create Teams, Groups, and SharePoint sites themselves, and global defaults are applied automatically. However, those defaults are generic, not risk-based, and often overly permissive.
Other organizations take the opposite approach, requiring users to raise a ticket to IT to provision a workspace. In reality, the same defaults are often reused, or admins rely on manual judgement to decide privacy and guest access.
The risk hasn’t been removed—it’s simply been shifted.
The real problem isn’t whether users or IT create workspaces. The problem is that very different collaboration scenarios are treated the same way.
Low-risk and high-risk collaboration often inherit the same controls or rely on manual decisions. What’s missing is a simple, consistent way to apply access controls based on risk.
This is the model I want you to remember: at the top, you have risk and policy decisions—what collaboration is allowed, where external access is appropriate, and where it isn’t.
Container Sensitivity Labels as the Translation Layer (00:01:37 – 00:02:03)
Nikki Chapple:
Container sensitivity labels sit in the middle as the translation layer.
They convert risk and policy decisions into enforced controls.
Those controls are then applied consistently across Teams, Groups, and SharePoint sites—regardless of whether the workspace is created by a user or provisioned by IT.
Now let me show you what that looks like in practice.
Creating an Internal Collaboration Label (00:02:03 – 00:04:34)
Nikki Chapple:
In this demo, I’m creating container sensitivity labels.
These are not data classification labels—they represent collaboration risk.
I’ll be creating one label for internal collaboration and another for external collaboration.
We start in the Purview Admin Center under Solutions → Information Protection → Sensitivity Labels.
We create a new label, provide an internal name, user description, and admin description.
Label color doesn’t apply here because this is for containers—not content.
We configure the label only for Groups, Teams, and Sites. We don’t want files or emails.
Under protection settings, we define controls for groups and sites.
The first setting is privacy.
Normally, users creating a Microsoft 365 Group or Team can choose public or private.
Remember: a public SharePoint site includes “Everyone except external users” permissions. That means even if someone is not a member of the Team or Group, they may still have access to the SharePoint site behind the scenes.
If users have access, Copilot has access.
With container labels, we can enforce private access.
For this internal label, we disable external guests.
We also restrict SharePoint external sharing so files can only be shared inside the organization.
You can additionally link container labels to Conditional Access policies for controls like MFA, session restrictions, or terms of use.
We can configure discoverability for private Teams and define controls for shared channels.
For this internal scenario, we allow only internal users and prevent external Teams from being invited into shared channels.
Then we simply create the label.
Creating an External Collaboration Label (00:04:34 – 00:05:39)
Nikki Chapple:
Next, we create an external collaboration label.
The user-facing label name is “External,” with descriptions explaining its purpose.
Again, we target only Groups and Sites.
We still enforce privacy by keeping the workspace private.
However, this time we enable external access.
We configure external sharing permissions.
Selecting “New and existing guests” allows users to invite new external people directly into the Team.
Choosing “Existing guests” would require those users to already have a B2B identity in Entra.
In this example, we also allow users to discover private Teams.
Once configured, we save the label.
Publishing Labels and Enforcing Defaults (00:05:39 – 00:06:54)
Nikki Chapple:
After creating the labels, we need to publish them before users can access them.
Under Policies → Label Policies, I’ve already created a dedicated policy for container sensitivity labels.
In my example, I have three labels available: Internal, External, and Confidential.
We can define who can access these labels—either everyone or a subset of users and groups.
The important configuration here is applying defaults and enforcing labeling.
The default label is set to Internal.
Users are allowed to switch to External if appropriate.
Most importantly, we enable the setting that requires users to apply a label to their Groups and Sites.
Next, let’s look at how these labels work in practice.
Admin and End User Experience Demo (00:06:54 – 00:09:03)
Nikki Chapple:
First, from the admin perspective.
I’m in the SharePoint Admin Center creating a Team site.
A new option appears allowing me to choose a sensitivity label.
I select “Internal.”
Notice that privacy has been grayed out—I can’t change it. The control is enforced automatically.
Now let’s switch to the end user experience.
In Teams, users create a new Team as normal.
The Team is automatically marked as Private and assigned the Internal label by default.
Users can switch between permitted labels, but they cannot remove labeling altogether.
In my final demonstration, we look at an External Team.
When I hover over the label, users can see a helpful description explaining what the label means.
Because the Team is labeled External, I can add external members and share files externally.
Now compare that with an Internal Team.
Hovering over the label again shows the description.
When I try to add the same external user, it fails because external guests are not permitted.
Likewise, when attempting to share files externally from the SharePoint site or Files tab, sharing is restricted to users inside the organization.
Final Takeaways on Consistent Collaboration Governance (00:09:03 – 00:09:49)
Nikki Chapple:
Whether users create collaboration spaces themselves or IT does it for them, the goal should be the same.
Container sensitivity labels allow you to govern collaboration risk consistently—without slowing people down or relying on manual judgement.
If you do one thing after this session, review how your Groups, Teams, and Sites are created in your tenant.
Ask yourself:
Are access controls applied consistently—or just differently?
Thank you for your time today.