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 how many organizations (in my experience) operate, without always admitting it.

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" only allow access to people and groups you specifically authorize

*A simple example of three sensitivity labels in Microsoft Purview*

If you haven't embarked on a Purview implementation, why start with sensitivity labels first? If you get this foundation in place, everything else including AI, automation, teams and sites organization, retention policies, data loss prevention, and compliance become easier.

Microsoft's approach: powerful but a little overwhelming

Microsoft recommends 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 as needed. 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. While this maximizes security, it can create significant user friction if your organization isn't ready for widespread encryption. If your users currently struggle with basic file sharing permissions, jumping straight into encrypted-by-default content will likely result in frustrated users and poor adoption.

I have seen issues with some of the wording and how they show up in the user experience as well. Specifically:

Public can be unclear if people are not used to sharing info publicly (so they would avoid that mostly).
"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:

A simpler starting point: three labels

For small to medium organizations just starting their Sensitivity Label journey, I recommend a "Starter Pack" of three labels, with no sub-labels, for a streamlined approach:

General: for content that doesn't need encryption, and is mostly internal
Confidential: for internal-only and encrypted content
Confidential – External Use: to explicitly label files and containers that are viewable externally, with encryption being optional

This is the breakdown:

Label Name	Description	Encryption	External Sharing
General	Internal data that isn't intended for public consumption, but could be shared with external partners, as required.	No	Yes, when allowed
Confidential	Sensitive data requiring protection, accessible to only internal staff	Yes	No
Confidential – External Use	Confidential content that needs external sharing	Yes or No	Yes, when allowed

If you don't need to share confidential information with external parties like lawyers or vendors, than maybe you don't even that last one. But I like it as an option for people to get around sharing issues for Confidential info.

Encryption is optional for sharing externally as well, as it depends on the apps you and your collaborators externally use. There might be compatibility issues or add-ons that don't work with encryption, so it's important to test before deploying broadly.

Why this works (for starter use cases)

General: Works for project documents, meeting notes, and business communications that might need external sharing. No encryption means no user friction while sharing.

Confidential: Introduces your users to encryption in a controlled way. HR documents, financial reports, and strategic plans get automatic protection.

Confidential - External Use: Handles the real-world scenario where confidential information must be shared externally—like sharing a proposal with a potential client or legal documents with a lawyer.

As your organization and information scale, take this and build on it. You might need Highly Confidential, or the default label set to have encryption (which is easier to do after people are somewhat familiar with labelling).

Real-World Implementation Examples

Scenario 1: Engineering Firm or other B2B firm

General: Client briefs, project timelines, creative assets
Confidential: Client contracts, financial projections, employee contracts and other HR info
Confidential - External Use: Proposals shared with prospective clients when pricing or details are sensitive

Scenario 2: Healthcare Organization or Government Agency

In this scenario, I suggest a slightly different version with no explicit external category but a similar "Highly Confidential" label:

General: Office policies, general communications, training materials, externally-sharable information
Confidential: Administrative documents, vendor contracts
Highly Confidential: Patient data, 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 3-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.

Your future self will thank you for starting with a foundation that users actually understand and adopt, rather than a complex system that sits unused while your data remains unprotected.

A simple starter kit for Microsoft Purview sensitivity labels