A Blueprint for Microsoft Purview Sensitivity Labels
Most organizations are sitting on thousands of documents, emails, and files scattered across SharePoint, Teams, and OneDrive. Some contain public information, and some is highly sensitive like employment contracts.
“Security by obscurity” is an accidental security model some organizations end up in! 😊
This is a problem not only for accidental data leaks, but also for discovery through AI tools such as Copilot.
What’s the solution?
Well, nothing can guarantee 100% security, but there are preventative measures to take.
Sensitivity labels are a key part of information protection in the Microsoft ecosystem.
They're a classification system that makes protection not only automatic but prevents people from making innocent mistakes—such as turning a SharePoint site's privacy setting from Private to Public by accident and now everyone can find financial data or employee records.
In this post, I share a simple 'starter design kit' for labels if your organization is getting started with sensitivity labels. And, keep in mind: sensitivity labels are an ongoing journey—not a one-and-done! So, don’t worry if it’s not perfect on day one.
Quick overview of sensitivity labels
Think of sensitivity labels as smart stickers for your data. Once applied, they automatically enforce protection rules without your users having to think about additional settings or permissions.
Here's what this looks like in practice:
An HR document labeled "Confidential" automatically encrypts and blocks external sharing, no IT intervention needed
A project plan labeled "General" can be safely shared with external contractors without triggering security alerts
Financial reports labeled "Highly Confidential" (or “Restricted” or “Protected”) which only allows access to people and groups you specifically authorize
A simple example of four sensitivity labels in Microsoft Purview:
A simple model for Purview sensitivity labels
If you haven't embarked on a Purview implementation, why start with sensitivity labels? Because it’s a core foundation for other features and business process tools in the M365 platform. AI, teams and sites organization, retention policies, data loss prevention, and compliance all become easier with sensitivity labels in place first.
Microsoft's approach: Powerful but a little overwhelming
Microsoft provides a robust starting point for sensitivity labels which we can look to for inspiration. They recommend a "Secure by Default" model, which includes eight different labels with complex encryption settings:
| Label name | Notes on settings |
|---|---|
| Public | Data that is approved for public consumption. No special settings for encryption, markings. |
| General | Not intended for public viewing, but can be shared with external partners. This content is not encrypted. Site privacy is either Private or Public. |
| Confidential \ All Employees | Confidential data that is encrypted and allows all employees to access. Note: Microsoft recommends this label as the default label for documents and sites. |
| Confidential \ Specific People | Confidential data that can be shared with trusted people inside and outside your organization. Encryption is optional or prompted. |
| Confidential \ Internal Exception | Confidential data that doesn't need encryption, e.g., when sharing with trusted external people. |
| Highly Confidential \ All Employees | Highly confidential data where only the data owner(s) can update the label or revoke. All employees can view, edit, and reply. |
| Highly Confidential \ Specific People | Highly confidential data that requires protection and can be viewed only by people you specify and with the permission level you choose. |
| Highly Confidential \ Internal Exception | Highly confidential data that doesn’t need to be encrypted. Use this option with care and appropriate business justification. |
Review the full approach and recommended settings from Microsoft: Start with default labeling | Microsoft Learn
The strength of Microsoft's Secure by Default model is that content, sites and email are more secure than with the setup that comes by default, with no labels deployed.
There are a few challenges though. The main one, in my experience, is that Microsoft recommends making "Confidential \ All Employees" (with encryption) the default label for all new content. In addition, they recommend that it’s automatically applied.
While this maximizes security, it can create user friction if your organization isn't ready for widespread encryption, or even labelling in general. If your users currently struggle with basic file sharing permissions, jumping straight into labels that are encrypted-by-default will likely result in frustrated users and poor adoption.
Depending on your audience, wording may cause confusion too. Specifically:
"Internal Exception" doesn't really make sense as a term to most people without more explanation. I prefer something easier to understand like "Anyone" which also suggests it's more open than "All Employees."
Highly Confidential vs. Confidential is difficult for most people to understand at a glance. Does a list of employees and their salaries go in Confidential or Highly Confidential? I recommend either not using Highly Confidential as a label at the start, or deploying it to specific users or departments that handle the most sensitive data and get special training on its use. Microsoft also recommends that Highly Confidential is deployed with an auto-labeling policy.
This is a minor quip, but long labels with label + sub-label text are extra clutter at the top of sites:
Purview Sensitivity on a SharePoint site
A simpler starting point: 4 labels
For small to medium organizations just starting their Sensitivity Label journey, we recommend a "Starter Pack" of four labels, with no sub-labels, for a streamlined approach:
Public or External: for public or external-facing content
General or Internal: for content that doesn't need encryption and is mostly internal. Use General if sometimes you share project sites or other assets with external vendors.
Confidential: for internal-only and encrypted content
Restricted: to explicitly label files and containers that are highly confidential such as PII, PHI, etc.
This is the breakdown:
| Label name | Description | Encryption | External sharing |
|---|---|---|---|
| Public or External | Content that goes on the external facing website | No | Yes |
| General or Internal | Internal data that isn't intended for public consumption, but could be shared with external partners, as required. These are things that go on the intranet, collaboration sites, published policies, etc. | No | Yes, when allowed |
| Confidential | Sensitive data, privileged or data with Personal information (PI) that requires protection | Yes | No, (usually) content is accessible to internal staff only or specific business units |
| Restricted | Highly confidential content including privileged information, PI, sensitive leadership content. This content may need additional protection with data loss provisioning features, blocks from AI tools etc. | Yes | No, content is accessible to specific staff or business units |
If you need to share confidential information, such as contracts, directly with external parties like lawyers or vendors, then you can set Confidential to allow external sharing, or add a sub label for Confidential that allows external sharing.
With any label using encryption, there might be compatibility issues or add-ons that don't work, so it's important to test before deploying broadly.
Implementation examples
-
Public: Marketing content, press releases, team bios
General: Client briefs, project timelines, creative assets
Confidential: Client contracts, financial projections, employee contracts and other HR info
Restricted: Employee records, intellectual property content
-
Public: Bylaws, Council agendas, patient policies or forms
Internal: Office policies, general communications, training materials, forms
Confidential: Administrative documents, vendor contracts
Restricted: Patient data, employee records, medical information (with strict access controls). This label is likely only deployed to a subset of the organization who handles highly sensitive information.
Of course, the sensitivity label design you choose will vary by the type of information that is handled, sharing requirements, and the personas or departments who handle different types of data.
Summary
In short, start sensitivity labels with a simple four-label approach and deploy to pilot groups of users before growing from there.
Remember that sensitivity labels are a journey, not a destination. The goal isn't perfection from day one—it's building a culture where data protection becomes second nature. Start with a simple, user-friendly system to ensure adoption and protect your data, rather than an unused complex solution.
If you need guidance or support in designing or deploying sensitivity labels, don't hesitate to reach out to Gravity Union for advice.
