Sensitivity Labels are classification and protection tags in Microsoft 365 that assign a confidentiality level to documents, emails, Teams, and SharePoint sites. They operate on two layers: classification (visible marking with header, footer, or watermark) and optional encryption with granular permissions. For a successful start, classification without encryption is usually sufficient — it already removes roughly 80% of the project complexity.
When an IT administrator needs to prevent sensitive documents from being accidentally shared with external recipients, uncontrolled guest accounts, or AI systems, preventive Microsoft Teams governance helps - they need a mechanism that makes confidentiality levels consistently visible and, where required, technically enforced — without the rollout taking months or blocking end users.
What are Sensitivity Labels and how do they work?
A Sensitivity Label operates on two effect layers that can be deployed independently of each other.
Layer 1: Classification. The label visualizes the confidentiality level on the document, SharePoint site, or Team. End users see a marking such as 'Internal', 'Confidential', or 'Highly Confidential' directly in the user interface. Headers, footers, and watermarks with freely definable text can also be added.
Layer 2: Encryption and permissions. The document is technically encrypted, and a separate permission layer is defined at the label itself — in addition to existing SharePoint permissions. This means: even if a document is accidentally shared with 'Everyone except external users', nobody who is not explicitly authorized at the label level can open it.
Important: You do not need to introduce both layers at the same time. Pure classification without encryption already has a significant effect — simply making Highly Confidential or Do not use with AI visible changes user behavior measurably and eliminates 80% of project complexity up front.
What is the difference between the container layer and the data layer?
Sensitivity Labels can be applied on two fundamentally different layers — and most mistakes arise because this distinction is not understood.
| Criterion | Container Layer | Data Layer |
|---|---|---|
| Applies to | Teams, Microsoft 365 Groups, SharePoint sites | Documents, emails, Teams meetings, chats, Power BI, Fabric |
| Effect | Sets group/site settings (guests, privacy, unmanaged devices) | Marks and protects the content itself |
| Encryption | No — settings only | Optional — including permissions |
| Inheritance to documents | No inheritance | Directly on the document |
| Content marking | Not available | Header, footer, watermark possible |
Container labels control the configuration of the group or site: who may be added as a guest, which access types are permitted for unmanaged devices, whether the Team is private or public. The label sets these configurations but has no influence on documents within the SharePoint library.
An important pitfall with container labels: If you remove the label, the settings that were applied are not rolled back. If a label set a SharePoint site to 'no external sharing' and you remove the label, 'no external sharing' remains in place. Anyone removing a label must reset the settings manually or via script.
How do I implement Sensitivity Labels correctly?
A successful implementation follows a clear sequence of phases. Trying to do too much at once leads to inconsistently labeled documents, frustrated end users, and permission conflicts.
Phase 1: Label Definition with a Small Group
The first step is defining the labels themselves — and here, the rule is: involve as few people as possible. We recommend one representative each from IT, data protection, and the CISO department, as well as one or two representatives from the business units.
Phase 2: Classification without encryption
Start exclusively with the classification level. No encryption, no permissions — just visible labels with optional headers, footers, and watermarks. This drastically reduces technical complexity while still delivering a significant portion of the benefits.
Phase 3: Define the removal and escalation process
Before labels go live, clarify the following: Who is authorized to remove or downgrade labels? What is the process if an encrypted document needs to be made accessible because the owner has left the company?
Phase 4: Pilot rollout with a test group
First, roll out labels to a small test group — 10 to 30 people in various roles. Gather feedback on label names, default behavior, and usability before rolling out more broadly.
Phase 5: Global Rollout and Phased Expansion
After a successful pilot: global rollout of the classification labels. Only then should you expand to include encryption, data loss prevention policies, eDiscovery integration, and — if at all — Auto-Labeling.
What are the key best practices for Sensitivity Labels?
Few labels, clear hierarchy
More than five or six labels overwhelm end users. When faced with 20 labels, a user is likely to choose the wrong one — or none at all. A typical, effective structure includes: Public, Internal, Confidential, Highly Confidential, and a special label such as 'No AI' or 'Restricted'.
Start with classification, not encryption
Encryption is the more technically and organizationally demanding step. It requires clear authorization models, key management, license verification, and escalation processes. Classification alone can be implemented in a matter of days and already produces measurable results.
Save Auto-Labeling for the end of the project phase
Auto-Labeling sounds appealing, but it carries significant risks. False positives can lead to documents being misclassified and, in the worst case, incorrectly encrypted — resulting in a significant amount of manual cleanup work.
How do I set default Sensitivity Labels on SharePoint libraries automatically?
Microsoft provides no built-in mechanism to set a default Sensitivity Label on associated document libraries based on rules per Team type or SharePoint site type. Administrators must configure the setting manually per library after each Team or site creation.
This is exactly the gap that Valprovia Governance closes. When provisioning a new Team or SharePoint site, the defined default Sensitivity Label is automatically applied to the associated document library. The rule applies per Team type or site type — without any manual follow-up, consistent across the entire tenant.
Summary
Sensitivity Labels are one of the most effective tools for systematically enforcing data classification and access protection in Microsoft 365 — provided the rollout follows a clear phase sequence. Start with pure classification, keep the label count lean, define processes for downgrading and removal, and save Auto-Labeling for last. The greatest organizational lever is not in the technical configuration — it lies in consistent application.
Book a demo now: See how Valprovia Governance sets default Sensitivity Labels rule-based on SharePoint libraries and provisions new Teams with consistent classification from the start.
Frequently asked questions about Sensitivity Labels in Microsoft 365
-
What are Sensitivity Labels in Microsoft 365?
Sensitivity Labels are classification and protection tags in Microsoft 365 that assign a confidentiality level to documents, emails, Teams, and SharePoint sites. They operate on two layers that can be deployed independently: classification (a visible marking such as Internal or Confidential, optionally with header, footer, or watermark) and optional encryption with a separate permission layer defined at the label itself.
-
What is the difference between container labels and data labels?
Container labels apply to Teams, Microsoft 365 Groups, and SharePoint sites and control their settings — guest access, privacy, and access from unmanaged devices; they do not encrypt anything and are not inherited by documents. Data labels apply to documents, emails, meetings, and chats: they mark and protect the content itself, enable content marking, and optionally encryption that can even override SharePoint permissions.
-
Should I start with classification or encryption?
Start with classification, not encryption. Simply making a confidentiality level visible changes user behavior measurably and eliminates roughly 80% of project complexity up front. Classification alone can be implemented in a matter of days. Encryption is the more demanding step, requiring clear authorization models, key management, license verification, and escalation processes — it should follow only once manual classification is established.
-
How many Sensitivity Labels should I define?
More than five or six labels overwhelm end users — faced with 20 labels, a user chooses the wrong one or none at all. A typical, effective structure is: Public, Internal, Confidential, Highly Confidential, and a special label such as No AI or Restricted. Involve as few people as possible in label definition: one representative each from IT, data protection, and the CISO department, plus one or two from the business units.
-
What happens if I remove a container label?
If you remove a container label, the settings that were applied are not rolled back. If a label set a SharePoint site to 'no external sharing' and you remove the label, that setting remains in place. Only switching to a different label synchronizes the new label's settings. Anyone removing a label must reset the settings manually or via script.
-
How does Valprovia Governance set default Sensitivity Labels automatically?
Microsoft provides no built-in mechanism to set a default Sensitivity Label on associated document libraries based on rules per Team type or site type — administrators must configure the setting manually per library after each creation. Valprovia Governance closes this gap: when provisioning a new Team or SharePoint site, the defined default label is applied automatically to the library, per Team type or site type and consistent across the entire tenant.
