Sensitivity Labels

Sensitivity labels are Microsoft Purview's mechanism for classifying and protecting content. Administrators publish a label taxonomy — for example, Public, Internal, Confidential, Highly Confidential — and users apply labels to documents, emails, Teams meetings, and SharePoint sites. Each label can apply protections automatically: encryption with usage rights, headers and footers, watermarks, sharing restrictions, container-level controls (external sharing settings, guest access, device requirements), and DLP triggers. Labels travel with the content even outside the tenant. They're the centrepiece of Microsoft 365 information protection and an important prerequisite for safely rolling out Microsoft 365 Copilot at scale.

File labels vs container labels

Labels operate at two distinct levels that are easy to conflate. A file or email label attaches to an individual document or message and, when it carries encryption, travels with that file wherever it goes — if it's emailed to an external partner, uploaded to a non-Microsoft cloud service, or copied to a USB drive, the encryption and usage rights (view-only, no-forward, no-print) still apply, because they're embedded in the file itself rather than enforced by the location it happens to sit in. A container label applies instead to a SharePoint site, a Teams team, or a Microsoft 365 Group as a whole, controlling site-level settings like whether external sharing is allowed at all, whether guests can be added, and whether access requires a compliant or hybrid-joined device — it governs the container's policy, not the encryption of any one file inside it.

Worked example

A legal team's SharePoint site is given a container label requiring private (not public) Teams-team privacy, blocking external sharing entirely, and requiring a compliant device for access. Individually, a merger-related draft document inside that site is additionally labelled "Highly Confidential — Legal Only," which applies encryption and restricts who can even open it (typically to named individuals or a specific group) regardless of who else has access to the site itself. If someone with access to the site downloads that document and emails it to a personal address by mistake, the file-level label's encryption still enforces its access restriction at the recipient's end — because the protection is bound to the file, the container the file used to live in no longer matters once it's left.

Default labels and mandatory labelling

Two adoption levers matter more than the taxonomy itself: a default label applied automatically to new documents and emails (so nothing is ever genuinely unlabelled by omission) and mandatory labelling, which blocks saving a document or sending an email until a label has been chosen. Tenants that only make labelling available, without a sensible default and without mandatory prompts for at least the highest-risk locations, typically see low real-world adoption — users don't proactively label content they didn't already think of as sensitive, which is precisely the content DLP and Copilot's oversharing controls most need labelled correctly.

Common pitfalls

Publishing too many labels (a taxonomy with a dozen fine-grained tiers) reliably fails in practice — users can't reliably choose correctly between "Confidential" and "Highly Restricted — Internal" under time pressure, and inconsistent labelling is worse for downstream DLP and Copilot governance than a simpler four-tier taxonomy applied consistently. The second common mistake is publishing labels without first testing their protections against the file types and workflows actually in use — for example, an encryption-bearing label applied broadly can break co-authoring or third-party integrations that don't support Microsoft's rights-management protocol, which is worth testing in a pilot group before a tenant-wide mandatory rollout.