The Label on the Door Does Not Protect What Is Inside

Here is the misconception that derails more sensitivity label deployments than any other: if I label the Teams site or SharePoint container as Confidential, everything inside it is protected.

It is not.

This is not a bug, an oversight, or a gap Microsoft has been slow to close. It is a deliberate architectural decision — and once you understand why it was made, the whole labeling model starts to make a lot more sense. Container labels and file labels are different instruments solving different problems. Using one does not substitute for the other. A complete governance posture requires both.

One Team, Two Sites, One Labeling Reality

When someone creates a Microsoft Team, they are not just creating a collaboration space. They are creating a Microsoft 365 Group, a SharePoint site, a shared mailbox, and a document library — all in a single provisioning action. Most end users have no idea this is happening. Many IT administrators know it intellectually but do not always govern accordingly.

From a sensitivity labeling perspective, this matters because the label you apply to a Teams container propagates to the underlying SharePoint site and the Microsoft 365 Group simultaneously (https://learn.microsoft.com/en-us/purview/sensitivity-labels-teams-groups-sites). Shared channels within that team automatically inherit the label from the parent team, and that label cannot be removed or replaced with a different label. So container labels do propagate — just not to files. They propagate to the collaborative workspace settings: privacy (public vs. private), guest access, external sharing behavior, default sharing link type, and access from unmanaged devices.

Think of the container label as the zoning designation for a piece of land. It determines what can be built there, who can enter, and what the rules are for the surrounding area. It does not tell you anything about what is inside the buildings.

What Container Labels Actually Enforce

When you apply a sensitivity label to a Teams site or SharePoint site at the container level, you are enforcing a set of workspace-level policies. A “Confidential” container label might configure the site as private, disable guest access, restrict external sharing to existing guests only, block access from unmanaged devices, and set the default sharing link to “People with existing access” rather than “Anyone.”

Those are meaningful controls. They prevent the most common categories of accidental oversharing at the workspace level — the unintentional guest invitation, the “Anyone with the link” share that escapes the organization entirely, the unmanaged personal device downloading sensitive materials. For a Copilot-enabled tenant, container labels are one of the fastest ways to reduce oversharing risk at scale without requiring large migration projects (https://nikkichapple.com/configure-container-sensitivity-labels-microsoft-365/).

But none of those controls classify or protect the individual files stored within the container. A document sitting in a “Confidential” SharePoint library carries no sensitivity label of its own unless one has been applied directly to the file — either manually by the user, automatically by a Purview auto-labeling policy, or through a default label policy configured for that library.

That last option — library-level default labels — is where the two layers start working together, and it is worth understanding how.

Default Labels and the Inheritance Gap

SharePoint allows administrators to configure a default sensitivity label for a document library. When a user uploads or creates a new file in that library, it automatically receives the configured default label (https://learn.microsoft.com/en-us/purview/sensitivity-labels-sharepoint-onedrive-files). This is the closest the platform comes to automatic inheritance between container and file — and it is not inheritance in the strict technical sense. It is a default applied at creation time.

The distinction matters for existing content. A library configured with a default label applies that label to new files going forward. Documents that already existed in the library before the default was configured are not retroactively labeled. That legacy content gap is exactly why auto-labeling policies in Purview are important — they scan existing content and apply labels based on sensitive information types, closing the coverage gap that default labels alone cannot address.

Microsoft has been expanding label inheritance capabilities meaningfully. As of mid-2026, Teams meeting artifacts — transcripts, recordings, and Loop meeting notes — can now inherit the sensitivity label applied to the meeting itself, reducing the manual labeling burden on meeting organizers and ensuring that a confidential discussion produces consistently protected artifacts (https://m365admin.handsontek.net/microsoft-purview-information-protection-sensitivity-label-inheritance-teams-meeting-artifacts-3/). This capability requires admin configuration and is not enabled by default, so it is worth checking your Purview roadmap items if you have not already.

Designing the Two-Layer Model

A complete container and file labeling architecture looks like this in practice:

The container label governs workspace behavior. Apply it at provisioning time — ideally through a provisioning workflow that maps workspace purpose to label, rather than leaving the decision to the person clicking “Create team.” A finance team workspace gets “Confidential” or “Highly Confidential” by default. A general project workspace gets “General.” The label sets the environmental rules before the first file is ever uploaded.

The file label governs content protection. Configure default labels on high-sensitivity libraries so that new content is labeled at creation. Layer auto-labeling policies on top to catch sensitive information types across existing content. Use mandatory labeling for specific user populations — legal, HR, executive communications — where manual classification accountability matters. For everyone else, let the defaults and automation do most of the work so that the governance system stays invisible to the average user.

These two layers reinforce each other. A “Highly Confidential” container label restricts who can access the workspace. A “Highly Confidential” file label encrypts the document and travels with it if it leaves the workspace. Together, they provide defense in depth. Separately, each leaves a gap the other cannot fill.

The architecture is not complicated. But it requires intentionality that most deployments skip in the rush to get Copilot enabled and users productive. The container label on the door matters. So does what is behind it.