Purview Sensitivity Labels: The Only Guide You Need in 2026

Most Microsoft 365 tenants have sensitivity labels configured. Very few have a taxonomy that is complete, consistently enforced, and ready for Copilot. That gap is about to get expensive.

Copilot for Microsoft 365 surfaces, summarizes, and generates content based on whatever the signed-in user can access. Sensitivity labels (specifically labels with encryption) are one of the few controls that can gate what Copilot actually processes. A well-designed taxonomy is no longer a compliance thoroughness exercise. In 2026, a broken one is a data exposure incident waiting to happen.

This guide is written for security engineers and compliance administrators who already know their way around the Purview portal. It is not a portal walkthrough. It is a control-plane design reference: what a sound taxonomy looks like, exactly how labels interact with Copilot (including the encryption detail most guides get wrong), and the enforcement sequence that avoids the failure modes that plague most deployments.

Why Most Label Taxonomies Are Broken

Before prescribing architecture, it helps to name the failure patterns. After deploying or inheriting a label taxonomy, most tenants have at least two of these five problems:

1. Too many labels. Tenants with more than 10–12 labels (flat or nested) see lower user adoption and higher mislabeling rates. Microsoft recommends a maximum of five primary labels with up to five sub-labels per parent. More than that adds cognitive load without adding coverage.

2. Labels without enforcement. Labels scoped to "Files & Emails" but with no DLP policies attached are visual markers only. They generate no protective effect beyond user awareness. Many tenants create labels and stop there, producing a false sense of coverage they cannot actually verify.

3. Missing mandatory labeling. Without a mandatory labeling policy, users can create and share unlabeled content indefinitely. This is the single most common gap. The label fundamentals documentation makes clear that mandatory labeling requires a policy applied to user groups: creating labels alone does nothing. Until mandatory labeling is active, coverage data from Content Explorer is unreliable.

4. Inconsistent scope. Labels scoped only to files and email leave container-level classification (SharePoint sites, Teams groups) entirely uncontrolled. Teams and SharePoint site-level labeling is configured through a separate groups and sites scope, and many orgs never activate it.

5. No auto-labeling on high-value content. Financial, HR, and legal document stores typically rely on manual classification (the exact content types where misclassification is costliest). Auto-labeling (P2 only) solves this; most E3 tenants leave it unaddressed.

The Recommended Taxonomy Architecture

The foundation is Microsoft's canonical four-tier model, which ships as the default in the Purview deployment wizard:

• Public — intentionally shared outside the organization
• General — internal-use, not sensitive
• Confidential — business-sensitive, restricted sharing
• Highly Confidential — regulated or high-impact, strict controls

For most enterprise deployments, sub-labels under Confidential and Highly Confidential carry the operational detail:

• Confidential / All Employees — no external sharing
• Confidential / Trusted Partners — B2B sharing permitted with specific domains
• Highly Confidential / Legal Hold — encrypted, full audit trail
• Highly Confidential / Executive — encrypted with RMS template scoped to a leadership group

One hard constraint: sub-labels are not supported for container labeling (SharePoint sites and Teams groups) as of early 2026. Only parent labels can be applied at the site and group level. Design parent label names to stand alone: users will see Confidential as their site-level option even when sub-labels exist in file contexts.

Encryption decisions. Labels above General tier should apply Azure Rights Management (RMS) encryption in most enterprise designs. Labels without encryption remain valid (they enable DLP policy scoping and audit logging), but the decision must be explicit. If you apply encryption, you own the RMS template configuration. If you do not, DLP is the compensating control. Do not leave this implicit. For a ready-to-deploy label taxonomy template and baseline DLP configurations, see our Purview Starter.

Taxonomy sufficiency checklist. Before creating enforcement policies, verify:

• Five or fewer primary labels, each with a clear and distinct use case
• Every label at Confidential tier or above has a defined encryption decision (on or off, deliberately)
• Sub-labels exist only where the distinction is meaningful to end users
• Labels are scoped to both files/email AND to groups/sites (two separate scope configurations)
• No pure-marker labels: every label has either DLP coverage or encryption applied

How Sensitivity Labels Interact with Copilot for Microsoft 365

This is where most deployment guides fail. The Copilot-label interaction depends entirely on whether the label applies encryption. The two cases behave differently, and conflating them is a real security mistake.

Labels with encryption (RMS applied)

Copilot for Microsoft 365 (including Microsoft 365 Chat and Business Chat) cannot process encrypted content that the signed-in user lacks decryption rights to. If a user does not hold the RMS usage rights to decrypt a file, Copilot cannot summarize, reference, or aggregate that file.

The critical implication: if the user does hold decryption rights (because the RMS template grants them access), Copilot will process that content, and can surface it across document boundaries in summarized responses. Encryption prevents unauthorized access. It does not prevent authorized users from having Copilot aggregate everything they are legitimately allowed to read.

This makes RMS template membership the real control surface. An encrypted label assigned to a group of 2,000 users does not meaningfully restrict Copilot's reach for any individual in that group. Review RMS template scope before treating encryption as a Copilot guardrail.

Labels without encryption

Labels without encryption do not restrict Copilot access. Copilot will process any content the user can reach through standard SharePoint permissions and RBAC assignments, regardless of what label is applied. These labels still provide value (they enable DLP policy scoping and audit visibility), but they are not access controls for Copilot.

DLP as the compensating control

DLP policies can be scoped to the Microsoft 365 Copilot workload. A DLP policy can block Copilot from pasting, sharing, or exporting labeled content outside permitted contexts, even when the user has read access. For Confidential content that carries visual-only labels (no encryption), a Copilot-scoped DLP policy is the correct compensating control.

The Copilot Pages inheritance gap

As of Q1 2026, Copilot Pages (AI-generated collaborative documents) do not automatically inherit the sensitivity label of the source documents used to generate them. Microsoft has acknowledged this as an open gap. Do not assume Copilot-generated output carries the source label. Verify this behavior in your tenant before relying on it for compliance purposes.

Design rule for Highly Confidential content: Apply encryption with a tightly scoped RMS template and a DLP policy targeting the Copilot workload. Either control alone has meaningful gaps. For a Copilot readiness checklist and prompt governance guide covering these controls, see our Purview + Copilot Starter.

Licensing Reality: What Works at E3 vs. E5

The capability boundary most organizations get wrong is not auto-labeling: it is mandatory labeling.

Source: Microsoft 365 licensing guidance for security and compliance

The most underused E3 control is mandatory labeling. Many E3 security teams skip it because they conflate it with auto-labeling, which does require P2. Mandatory labeling requires only P1, and it is the highest-impact control available without a license upgrade. If you are an E3 org without mandatory labeling active, that is the first thing to fix.

One clarification: built-in sensitive information types (SITs) — credit card numbers, SSNs, passport patterns — are available at all license tiers. The P2 gate is not on SIT availability; it is on using those SITs to drive auto-labeling enforcement through service-side policies. E3 tenants can reference SITs in DLP policies; they cannot use them to automatically apply labels to SharePoint content at rest.

Enforcement Sequence: Mandatory First, Auto-Labeling Second

Deployment order matters. Failure modes from each phase compound into the next if the sequence is wrong.

1. Define the taxonomy first. Finalize labels before creating any policies. Taxonomy changes after encryption policies are live carry migration risk — files encrypted with an old RMS template retain that protection unless actively re-labeled or re-encrypted. Get the label set right before creating dependencies on it.

2. Deploy mandatory labeling. Apply a mandatory labeling policy to all users with a default label of General. Communicate before rollout. Users who receive a mandatory label prompt in Outlook while forwarding unlabeled external email will be blocked mid-workflow without warning. Verify that Outlook mobile client versions in your environment support mandatory labeling enforcement; client enforcement can lag desktop by several release cycles.

One timing dependency most guides skip: mandatory labeling should go live after the taxonomy is finalized and tested, not simultaneously with taxonomy rollout. Mandatory labeling requires users to classify every document and email at creation or send time. If users are not sure which label fits (because the taxonomy is still being socialized), they will default to General. That is not a user behavior problem. It is a premature deployment problem. The result is a corpus of content labeled General that does not reflect actual data sensitivity, and that mislabeled content will persist.

For P2 tenants planning to follow with auto-labeling: service-side auto-labeling policies do not override user-applied labels by default in most configurations. Files labeled General as a placeholder before auto-labeling was active will generally be skipped by auto-labeling enforcement. Correcting the mislabeling requires explicit override configuration, scripted re-labeling, or manual triage at scale. The labeling debt from premature mandatory labeling compounds precisely here, because auto-labeling cannot quietly fix it.

3. Simulate auto-labeling (P2 only). Before enabling any auto-labeling policy in enforcement mode, run it in simulation mode in the Purview portal for at least 24 hours. Review simulation results before activating — false positives in simulation become over-labeled content in production, and over-labeled content with encryption can break workflows.

4. Enable auto-labeling in enforcement mode. Start with high-confidence sensitive information type patterns (credit card numbers, passport numbers) before expanding to lower-confidence trainable classifiers. Progress from narrow and certain toward broad and probabilistic, not the reverse.

5. Layer DLP policies last. DLP policies built against an unstable or still-changing label taxonomy generate alert fatigue and false positives that undermine confidence in the tool. Get labels into steady state before building DLP logic on top of them.

Failure modes to anticipate:

• Lowest-friction label abuse: users always select General (or Public) regardless of content sensitivity, degrading label data quality. Address through user education and manager accountability before assuming mandatory labeling has solved coverage.
• OneDrive personal site gap: SharePoint auto-labeling does not process content in personal OneDrive sites unless explicitly scoped — a common hidden coverage gap.
• Re-labeling encrypted content: service-side auto-labeling cannot re-label files already encrypted with an RMS template if the service account lacks usage rights for that template. Pre-existing encrypted content requires manual or scripted re-labeling.

Platform Gaps: SharePoint, Teams, Exchange, and Copilot

Label behavior is not uniform across M365 workloads. These are the gaps that break assumptions.

SharePoint

Container labels applied to SharePoint sites control external sharing and governance behaviors at the site level. They do not cascade to documents inside the site — item labels and container labels are independent. A site labeled Confidential can contain documents labeled Public if no item-level labeling policy enforces otherwise.

Auto-labeling for very large libraries (over 500,000 items) requires batched activation due to crawler throttling. Plan activation in stages for large document repositories.

Teams

Teams channel files are stored in SharePoint and inherit the SharePoint site's container label. They do not receive independent item labels unless a file-level label is applied by a user or auto-labeling policy. Teams chat messages are stored in Exchange hidden folders and can be covered by DLP policies — but sensitivity label policies do not natively apply to chat messages the way they apply to email. Meeting transcript files are labeled at the file level in OneDrive, not at the meeting level.

Exchange

Mandatory labeling in Outlook applies to outbound email only. Inbound email from external senders arrives unlabeled. Exchange transport rules can auto-apply labels based on header conditions or domain patterns and will fire regardless of Outlook client version — but if both a transport rule and an auto-labeling policy target the same message, explicit policy precedence must be configured to avoid conflicts.

If you are restructuring a label taxonomy, Exchange transport rules that reference old labels by GUID or display name must be updated. Microsoft provides a migration tool for remapping Exchange transport rule label references when labels are renamed or deleted.

Copilot

Copilot Business Chat in web-grounded mode can access unlabeled or unencrypted SharePoint content the user has permission to reach, regardless of what label a site or document carries. Copilot audit events are written to the M365 Unified Audit Log under the CopilotInteraction event type. They do not appear in Activity Explorer as of early 2026.

Auditing That Labels Are Actually Working

Creating policies is not verification. These are the signal sources worth monitoring.

Content Explorer

Content Explorer provides a label-by-label inventory of labeled content across Exchange, SharePoint, OneDrive, and Teams. Full document-level drill-down requires the Content Explorer Content Viewer role — treat this as privileged access, not a routine reporting permission.

Use Content Explorer to validate that your label distribution reflects expected content composition. A tenant where 90% of content is labeled General and less than 1% is Highly Confidential may accurately reflect actual content composition — or it may reflect users defaulting to General to avoid friction. You cannot tell without examining the actual content.

Activity Explorer

Activity Explorer tracks label events: LabelApplied, LabelChanged, LabelRemoved, LabelUpgraded, LabelDowngraded. Native lookback is 30 days; export to Microsoft Sentinel or Log Analytics for longer retention.

The most actionable signal: high volume of LabelDowngraded events may indicate users systematically lowering label classifications to bypass DLP blocks. Route this to a SIEM alert, not just a periodic manual review.

Copilot summarization events are not currently visible in Activity Explorer. Copilot-specific audit data requires a separate Unified Audit Log query against CopilotInteraction.

DLP Reports

DLP policy match reports in the Purview compliance portal validate that labeled content is actually triggering the expected DLP controls. This is the behavioral proof that your policies are wired correctly — not just that they exist. If labeled Confidential content never appears in DLP policy matches, either the DLP conditions are misconfigured or the label is not being applied to the content you think it is.

Defender for Cloud Apps (if licensed)

For organizations that already have Microsoft Defender for Cloud Apps, session policies can enforce label-based controls for third-party cloud app access — blocking downloads of Highly Confidential files from unmanaged devices, for example. MDCA licensing is separate from E3/E5; do not plan around this capability if it is not already in scope.

Next Steps: What to Do in Your Tenant This Week

Audit your current taxonomy:

• Export the full label list from the Purview compliance portal
• Count primary labels (target: five or fewer) and sub-labels per parent
• Identify labels with no DLP policy attached and no encryption applied — these are pure-marker labels with no enforcement effect
• Verify that mandatory labeling policies exist and cover all licensed users

Check encryption scope:

• For each label with RMS encryption, open the RMS template and review group membership
• Flag any template scoped to groups larger than warranted — these are over-permissive Copilot access controls masquerading as encryption

Run a Copilot Pages spot check:

• If your org has Copilot for Microsoft 365 deployed, create a test Copilot Page from a Confidential source document
• Verify whether the generated page receives any sensitivity label
• If it does not, treat Copilot-generated output as unlabeled data until the inheritance gap is resolved

Activate mandatory labeling if not active:

• Mandatory labeling requires only P1 licensing — this is your first task if it is not deployed
• Set default label to General, deploy to all users, communicate the change before it goes live

Set a 30-day review cadence:

• Pull Activity Explorer LabelDowngraded events and review volume
• Pull Content Explorer label distribution and compare to your expected content composition baseline
• Review DLP policy match reports for at least one label condition per tier

If your org is at E5 or P2 licensing and auto-labeling is not yet deployed, identify your top three high-value document stores lacking coverage and run initial simulation scoped to high-confidence SIT patterns. Start narrow. Expand only after simulation output has been reviewed.

Sources: S-01 · S-02 · S-03 · S-04 · S-05 · S-06 · S-07 · S-08 · S-09 · S-10

Purview StarterEverything you need to establish a sensitivity label taxonomy and deploy baseline DLP policies in Microsoft Purview.TirionPurview + Copilot StarterPurview data protection essentials plus a Copilot for M365 readiness checklist and prompt governance guide — get your data estate ready before enabling AI.Tirion

Revision History

2026-04-08 — published

Updated mandatory labeling guidance to address label taxonomy vetting timing, auto-labeling override behavior, and converted the sufficiency checklist to a plain list.

2026-04-08 — published

Added inline CTAs and Ghost bookmark cards for the Purview Starter and Purview + Copilot Starter bundles.

2026-03-22 — published

Initial Publish