Microsoft Purview sensitivity labels — a deep dive

Sensitivity labels in Microsoft Purview are the mechanism for classifying and protecting content across Microsoft 365. A label is a piece of metadata stamped on a file, email, meeting, or container — and, crucially, a bundle of enforcement that follows the stamp. They're the centrepiece of Microsoft's information protection story, and since Copilot arrived they've been promoted from "compliance project" to "prerequisite for the AI rollout."

What a label does

When applied, a sensitivity label can:

• Apply encryption with usage rights — only defined users or groups can open the content, with optional restrictions on editing, printing, forwarding, and copying. This is Azure RMS underneath, and it travels: an encrypted file mailed outside the tenant stays encrypted.
• Add visual markings — headers, footers, watermarks.
• Set the default sharing link type and scope for labelled files.
• At the container level (sites, Teams, Microsoft 365 Groups): cap external sharing, control unmanaged-device access, set privacy, and bind Conditional Access authentication contexts.
• Act as a condition in DLP policies ("block external email containing Highly Confidential files") — see the DLP deep dive.
• Be mandatory, with a default label applied and users prompted on save or send.

Note what a label without encryption does: mostly nothing, directly — it marks and it feeds policy. That's fine. Classification-only labels plus DLP is a legitimate architecture, and much easier to live with than encrypting everything.

Taxonomy design — where projects live or die

The label taxonomy is the highest-stakes decision, because changing it after adoption is miserable. A shape that works for most organisations:

• Public — cleared for release. No controls.
• General (or Internal) — the default for everyday work. No encryption, no markings.
• Confidential, with sub-labels:
  • Confidential \ All Employees — encrypted, everyone in the org can open.
  • Confidential \ Specific People — the user picks recipients at labelling time.
• Highly Confidential, with sub-labels for the genuinely restricted material — named-audience encryption, no external sharing, strict container controls.

Rules of thumb that repeat across successful deployments:

• Five top-level labels maximum. Users have to make this choice dozens of times a day; a taxonomy they can't hold in their head is a taxonomy they'll misuse.
• Name labels by sensitivity, not by department or regulation. "Confidential" beats "GDPR-Art-9-Special-Category" every time.
• The default label matters more than the exotic ones. Ninety-something percent of content is General; make that path frictionless.
• Don't encrypt General. Broad encryption breaks third-party tools, complicates eDiscovery, and can wall content off from services that legitimately need it. Encrypt where the risk justifies the friction.

File labels vs container labels

Labels apply at two distinct levels, and the two are complementary, not redundant:

• Files and emails get encryption, markings, and DLP hooks.
• Containers (Teams, Microsoft 365 Groups, SharePoint sites) get sharing, privacy, and access posture — the controls covered in SharePoint external sharing.

A site labelled Confidential constrains the container — who can be invited, from which devices — while the files inside carry their own labels. A Confidential site full of General documents is normal and correct.

Automatic and recommended labelling

Users misclassify, so Purview supplements them:

• Recommended labelling — Office suggests a label when content matches sensitive information types ("This document appears to contain credit card numbers"). Low-friction, good adoption tool.
• Automatic labelling — client-side (as users type) or service-side auto-labelling policies that stamp labels on matching content at rest across SharePoint, OneDrive, and Exchange. This is how you deal with the terabytes that predate the labelling project — covered further in auto-labelling policies.

Start with recommendations, graduate to automatic once false-positive rates are understood. Auto-labelling that encrypts aggressively on a noisy classifier is a support-ticket machine.

Encryption mechanics — key management options

"Encrypt with Confidential" hides three different key-management models, and the choice matters for anyone with regulatory or sovereignty requirements:

• Microsoft-managed key — the default, and right for the overwhelming majority of tenants. Microsoft holds the root key in Azure Information Protection's key infrastructure; usage rights are still enforced per-user through Entra authentication on every open.
• Bring Your Own Key (BYOK) — the tenant generates the root key in Azure Key Vault and Microsoft uses it for encryption operations, but Microsoft's service still performs the cryptographic operations. This satisfies "we control the key" requirements without changing the user experience.
• Hold Your Own Key / Double Key Encryption (DKE) — the most restrictive option. One key is Microsoft-managed, the second is held entirely outside Microsoft (on-premises or in the customer's own infrastructure), and both are required to decrypt. Microsoft never has access to content protected this way — which also means Microsoft services that need to read content (Copilot, eDiscovery full-text search, SharePoint search, co-authoring) cannot act on it. DKE is a real tool for a narrow set of regulatory cases, not a default-good option — it trades away most of the platform's built-in intelligence for content that uses it.

For content that doesn't need DKE's isolation, the default managed key is what lets co-authoring, Copilot, eDiscovery, and search all keep working normally — which is why most information-protection programmes should treat DKE as an exception path for specifically flagged content, not a taxonomy tier.

Encryption, offline access, and revocation

A few mechanics worth knowing before the first "why can't I open this" ticket:

• Offline access is configurable per label — usage rights can be cached for a set number of days so a user can open encrypted content without a live connection, trading a little security for usability on laptops that travel.
• Revocation works because every open re-checks rights against Entra ID: revoke a user's access (remove them from the permissions list, or revoke the document outright from the Microsoft 365 admin center's document tracking) and the next open fails, even for a file already sitting on someone's disk. This is the property that makes "we sent it externally by mistake" recoverable in a way plain email attachments never are.
• Non-Office file types — PDFs get native encryption support in recent Office and Purview clients; other file types (images, CAD files, plain text) can be labelled and encrypted only through the Purview Information Protection client, the on-premises scanner, or via the unified labelling SDK in a custom application. Coverage here is the most common gap teams discover after rollout — don't assume "labels work everywhere" without checking the specific file types your organisation actually shares.

Copilot readiness

Microsoft 365 Copilot respects labels in two ways: encrypted content the user lacks usage rights to won't surface in Copilot answers, and Copilot-generated content inherits the label of its source material. That makes labels one of the few controls that constrain Copilot by content sensitivity rather than by raw permission — which is why every Copilot readiness checklist now includes "publish a baseline label taxonomy." Pair this with the permissions work in Copilot data access and permissions; labels without permission hygiene solve half the problem.

Licensing

Manual labelling of files and emails is included from Microsoft 365 E3 (and Business Premium). Automatic and recommended labelling, and the ML-based classifiers, require E5 or the Purview compliance add-ons. Container labelling sits in the E3-and-up tier but is commonly deployed alongside the E5 features. As ever with Purview, check the current service descriptions before building a business case — the packaging moves.

Rollout order

1. Design the taxonomy on paper, with the people who own the data — not just IT.
2. Publish labels in classification-only mode (no encryption) to everyone; make General the default.
3. Add container labels to new Teams/sites at creation time.
4. Turn on recommended labelling for the obvious sensitive information types.
5. Introduce encryption on the Confidential tier once support is ready for "I can't open this" tickets.
6. Point auto-labelling at legacy content, report-only first.

Labels are a change-management project wearing a technology costume. Small taxonomy, boring defaults, encryption last — that's the version that sticks.

Worked example: naming a taxonomy that a law firm can actually use

A 150-person law firm starts with a taxonomy borrowed from a template: Public, Internal, Confidential, Client Confidential, Highly Restricted, Privileged, Regulatory. Seven top-level labels, three of which overlap in practice — "Client Confidential" and "Privileged" both end up applied to nearly every client file, and nobody can articulate a rule for choosing between them.

The fix is a taxonomy collapse, not a taxonomy rebuild: Public, General (the new default, replacing Internal), Confidential (folding in the old Client Confidential — nearly everything client-related lands here), and Highly Confidential (folding in Privileged and Regulatory — the genuinely narrow-audience material). Four labels instead of seven. The rollout communication is honest about why: "Client Confidential and Privileged were the same label with two names; we picked one." Adoption improves within weeks, not because the new labels are smarter, but because there are fewer decisions to make per document.

Decision matrix: which label for which content

| Content | Typical label | Encryption? | Notes | | --- | --- | --- | --- | | Public marketing material, published pricing | Public | No | No controls needed; the point is unrestricted distribution | | Routine internal email, meeting notes, day-to-day drafts | General | No | The default; if this path has friction, adoption fails everywhere else | | Client files, contracts, anything with a named external counterparty | Confidential \ Specific People | Yes | Recipient list set at labelling time, not "everyone in the org" | | Board papers, M&A materials, unannounced financials | Highly Confidential | Yes, named-audience | Pair with container controls on the site or Team it lives in | | A Team or SharePoint site for a sensitive project | Container label at Confidential or above | Sharing/privacy only | Does not label the files inside — label those independently |

MSP checklist

• Publish the taxonomy design as a short internal document per client before touching the tenant — a taxonomy is a business decision the client owns, not a configuration a consultant should invent silently.
• Roll out classification-only first, across every client, before proposing encryption on any of them — a client's first experience with labelling should not be a support ticket about a file they can't open.
• Keep a standard four-or-five-label starting taxonomy for new clients and only add sub-labels when a specific client's regulatory or contractual requirement demands it — a bespoke taxonomy per client multiplies the training material an MSP has to maintain.
• Confirm licensing per client before promising automatic labelling or classifiers — Business Premium and E3 tenants get manual and container labelling only; automatic labelling needs E5 or the Purview add-ons on that specific tenant.