Sensitivity Labels in SharePoint and OneDrive: A Practical Governance Checklist for Microsoft 365 Admins

TL;DR

Sensitivity labels help Microsoft 365 organizations classify and protect sensitive content across SharePoint, OneDrive, Teams, Microsoft 365 Groups, and Office files.

For SharePoint admins, the key point is this:

Permissions decide who can access content. Sensitivity labels help define what the content is and what protection should follow it.

Before enabling or expanding sensitivity labels, organizations should review:

• SharePoint external sharing settings
• Existing site permissions
• Guest access patterns
• Sensitive libraries and business-critical content
• Microsoft Purview label taxonomy
• Site-level vs file-level label requirements
• User training and support process
• Copilot readiness and oversharing risk
• Audit and reporting requirements

Sensitivity labels work best when they are part of a broader governance model, not when they are treated as a standalone compliance checkbox.

---

Table of Contents

1. Why sensitivity labels matter in SharePoint and OneDrive
2. Permissions are not the same as information protection
3. File-level labels vs site-level labels
4. What changes when sensitivity labels are enabled for SharePoint and OneDrive
5. Common SharePoint governance problems sensitivity labels can help address
6. Common mistakes organizations make
7. Practical governance checklist for Microsoft 365 admins
8. Recommended label strategy for SharePoint environments
9. How sensitivity labels support Copilot readiness
10. What SharePoint admins should document
11. Final thoughts

---

Why sensitivity labels matter in SharePoint and OneDrive

SharePoint Online and OneDrive are usually where a large amount of organizational content lives.

That includes:

• HR documents
• Finance reports
• Legal files
• Contracts
• Project documentation
• Internal policies
• Client deliverables
• Executive presentations
• Exported reports
• Files shared through Microsoft Teams
• Documents shared with external vendors or partners

Traditionally, many organizations relied mostly on SharePoint permissions to protect this content.

That is still necessary, but it is not enough.

Permissions answer questions like:

• Who can open this site?
• Who can edit this document?
• Who can share this folder?
• Is this user a site owner, member, or visitor?

Sensitivity labels answer a different set of questions:

• Is this content public, internal, confidential, or highly confidential?
• Should this document be encrypted?
• Should users see a visual marking?
• Should this site allow external users?
• Should this workspace be public or private?
• Should unmanaged devices have limited access?
• Should this information be treated differently by compliance policies?

That distinction matters.

A SharePoint library can have correct permissions today, but a document can still be downloaded, copied, emailed, synchronized, or shared later depending on how the environment is configured. Sensitivity labels help organizations apply protection and classification that can travel with the content or apply governance settings to the container where collaboration happens.

---

Permissions are not the same as information protection

One mistake I see often is assuming that SharePoint permissions and sensitivity labels solve the same problem.

They do not.

SharePoint permissions are access controls. Sensitivity labels are classification and protection controls.

For example, a finance team site may have permissions configured correctly. Only finance users can access the site. That is good, but it does not automatically mean the documents are classified as confidential. It also does not automatically prevent users from downloading a sensitive file, emailing a copy, or placing similar content in a less secure location.

A sensitivity label can help identify that a file or workspace contains confidential data. Depending on the label configuration, it can also apply encryption, content markings, access restrictions, or site-level governance settings.

A practical governance model should use both:

Control	Main Purpose	Example
SharePoint permissions	Control access to sites, libraries, folders, and files	Only HR members can access the HR policy library
Sensitivity labels for files	Classify and protect documents	A payroll spreadsheet is labeled Highly Confidential
Sensitivity labels for containers	Apply governance settings to sites, groups, and teams	A confidential project site blocks or limits external sharing
DLP policies	Detect and control sensitive data movement	Prevent documents with credit card numbers from being shared externally
Retention policies	Manage lifecycle and records requirements	Keep legal documents for a defined retention period
Audit logs	Track activity and support investigations	Review when labels are applied, changed, or removed

The goal is not to replace permissions. The goal is to reduce risk by combining permissions, labels, DLP, retention, and audit controls into a more complete Microsoft 365 governance model.

If you are already reviewing SharePoint permissions governance, check out my post on building a SharePoint permission visualizer with SPFx.

---

File-level labels vs site-level labels

Sensitivity labels can apply to different scopes. For SharePoint and Microsoft 365 governance, the two most important concepts are file-level labels and container-level labels.

File-level sensitivity labels

File-level labels apply to individual documents or supported files.

Examples:

• A Word document labeled Confidential - Internal
• An Excel workbook labeled Highly Confidential - Finance
• A PowerPoint deck labeled Public
• A PDF labeled as sensitive after PDF support is enabled

Depending on how the label is configured, a file-level label can include:

• Classification metadata
• Encryption
• User access restrictions
• Content markings such as headers, footers, or watermarks
• Auto-labeling behavior
• Audit events when labels are applied, changed, or removed

This is useful when the protection needs to follow the document itself.

Site-level or container-level sensitivity labels

Container-level labels apply to collaboration spaces such as:

• SharePoint sites
• Microsoft Teams
• Microsoft 365 Groups
• Viva Engage communities
• Loop workspaces

These labels do not automatically label every file inside the site. Instead, they help control settings for the workspace.

Depending on configuration and licensing, container labels can influence settings such as:

• Site or group privacy
• External user access
• External sharing configuration
• Access from unmanaged devices

This is useful when the organization wants the workspace itself to follow a governance model.

For example:

• A public communication site might use a Public label.
• An internal department site might use an Internal label.
• A merger and acquisition project site might use a Highly Confidential label.
• A vendor collaboration site might use a Confidential - External Collaboration Allowed label.

The important point is that file-level and site-level labels solve related but different problems.

A site can be labeled confidential, but the documents inside still need their own document-level labeling strategy if the organization needs file-level classification, encryption, or markings.

---

What changes when sensitivity labels are enabled for SharePoint and OneDrive

Microsoft provides support for sensitivity labels in SharePoint and OneDrive so Office files, PDFs, and supported content can be processed in the service. This matters because SharePoint and OneDrive are where users commonly store and collaborate on sensitive content.

Once support is enabled and configured, organizations can benefit from scenarios such as:

• Users applying labels in Office files stored in SharePoint or OneDrive
• SharePoint and OneDrive processing labeled and encrypted Office files
• Office for the web working with supported labeled content
• Audit events for label activity
• Auto-labeling policies applying labels to matching content
• Support for additional file types as Microsoft expands Purview capabilities

Admins should not treat this as a simple toggle. Enabling the feature is only one part of the work. The harder part is designing labels, publishing policies, testing the user experience, validating external sharing behavior, and making sure support teams understand what changed.

---

Common SharePoint governance problems sensitivity labels can help address

Sensitivity labels can help with several common SharePoint and Microsoft 365 governance problems.

1. Oversharing sensitive content

SharePoint makes collaboration easy. That is one of its strengths.

But easy collaboration can also lead to oversharing.

Examples:

• A user shares a confidential document with the wrong external email address.
• A department creates a site with broad access and stores sensitive reports inside it.
• A Teams-connected SharePoint site allows guests, but nobody reviews what files are stored there.
• A project folder gets shared externally and remains accessible long after the project ends.

Sensitivity labels can help by making the classification of content and workspaces more visible. When combined with DLP and sharing policies, labels can also help enforce different rules for different sensitivity levels.

For more on identifying external sharing risk, see my post on building a SharePoint external sharing risk scanner with SPFx.

2. No clear difference between internal and confidential content

Many organizations have only two informal categories:

• Things everyone can see
• Things only some people should see

That is not enough for governance.

A practical label model can introduce clearer categories such as:

• Public
• Internal
• Confidential
• Highly Confidential
• Confidential - External Collaboration Allowed
• Highly Confidential - Restricted

The labels should be simple enough for users to understand, but specific enough for admins and compliance teams to enforce meaningful policies.

3. Guest access without classification

External sharing is not automatically bad. Many organizations need to collaborate with vendors, clients, contractors, and partners.

The problem is external sharing without context.

A vendor collaboration site is very different from an HR investigation site. A marketing campaign site is very different from a legal matter site.

Sensitivity labels can help define which workspaces are allowed to have external users and which should remain internal-only.

4. Copilot readiness concerns

Microsoft 365 Copilot respects existing permissions, but that does not mean organizations should ignore content governance.

If users already have broad access to outdated, sensitive, or poorly governed content, Copilot can surface information those users are technically allowed to access.

Sensitivity labels are one part of a safer Copilot readiness plan because they help organizations classify and protect content before AI makes information discovery easier.

For a deeper dive into this topic, see my SharePoint Copilot readiness checklist.

5. Lack of auditability

Organizations need to know when sensitive content changes classification.

Label-related audit events can help answer questions such as:

• Who applied a label?
• Who changed a label?
• Who removed a label?
• Which files are labeled as highly confidential?
• Are sensitive files being stored in unexpected locations?

Auditability is important for incident response, compliance reviews, and governance reporting.

---

Common mistakes organizations make

Sensitivity labels can add real value, but only when implemented carefully.

Here are common mistakes to avoid.

Mistake 1: Creating too many labels

A label taxonomy with 15 or 20 labels may look complete on paper, but it can overwhelm users.

If users do not understand the difference between labels, they will guess. When users guess, label quality becomes inconsistent.

Start with a smaller, practical set of labels and expand only when there is a real business reason.

Mistake 2: Using compliance language users do not understand

Labels should make sense to business users.

A label like CUI-HC-RG3-Restricted might make sense to a compliance team, but it may confuse a regular SharePoint user.

Better user-facing labels are usually clearer:

• Public
• Internal
• Confidential
• Highly Confidential
• Confidential - External Sharing Allowed
• Restricted

The technical configuration can still be detailed behind the scenes.

Mistake 3: Enabling labels before cleaning permissions

Sensitivity labels are not a shortcut for permission cleanup.

Before rolling out labels broadly, admins should review:

• Site owners
• Site members
• External users
• Sharing links
• Broken inheritance
• Anonymous links
• Stale Teams and SharePoint sites
• Over-permissioned libraries

If permissions are messy before labels are enabled, labels will not magically fix the environment.

For tips on managing inactive sites, see my post on managing inactive SharePoint sites.

Mistake 4: Forgetting about OneDrive

A lot of sensitive content starts in OneDrive before it moves to SharePoint or Teams.

Examples:

• Draft contracts
• Exported reports
• Client files
• Meeting notes
• Excel analysis files
• Documents shared directly from a user’s OneDrive

A good sensitivity label strategy should include OneDrive, not just SharePoint sites.

Mistake 5: Not testing with external users

External sharing behavior must be tested carefully.

Admins should test scenarios such as:

• Guest user opening a labeled document
• External user accessing a labeled SharePoint site
• User downloading an encrypted file
• User opening a document in Office for the web
• User opening a document in desktop Office apps
• User trying to share a highly confidential file externally
• User accessing content from an unmanaged device

The goal is to avoid surprises after rollout.

Mistake 6: Not preparing support teams

Users will ask questions.

Examples:

• Which label should I choose?
• Why can I not open this file?
• Why can my vendor not access this document?
• Why did this file get labeled automatically?
• Why can I not remove a label?
• Why does this site block guest access?

If the help desk and SharePoint admins are not prepared, sensitivity labels can quickly become a support problem.

---

Practical governance checklist for Microsoft 365 admins

Use this checklist before enabling or expanding sensitivity labels in SharePoint and OneDrive.

1. Review current SharePoint sharing settings

Start with the SharePoint admin center.

Review:

• Tenant-level external sharing setting
• Site-level external sharing setting
• Default sharing link type
• Anonymous link configuration
• Anyone links expiration
• File and folder link permissions
• Guest access restrictions
• Domain allow/block lists

Sensitivity labels should align with your sharing model.

If the tenant currently allows broad external sharing, a confidential label strategy should account for that.

2. Identify high-risk SharePoint sites

Not every site needs the same level of governance.

Prioritize sites that contain:

• HR data
• Finance data
• Legal data
• Executive content
• Customer records
• Contract documents
• Security documentation
• M&A information
• Board materials
• Regulated data

These sites should be reviewed first because they represent higher business risk.

3. Review existing permissions

Before labels, review access.

Check:

• Site owners
• Site members
• Site visitors
• Microsoft 365 Group owners
• Guest users
• Sharing links
• Unique permissions
• Direct file permissions
• Inactive users
• External accounts

A label strategy works better when permission hygiene is already under control.

4. Define label names and business meaning

Each label should have a clear purpose.

Example:

Label	Business Meaning	Example Content
Public	Approved for public sharing	Published brochures, public web content
Internal	For employees and approved internal users	Internal process documentation
Confidential	Sensitive business content	Contracts, internal financial summaries
Confidential - External Collaboration Allowed	Sensitive content that can be shared with approved partners	Vendor project files
Highly Confidential	Very sensitive content requiring restricted access	Payroll, legal matters, executive planning
Restricted	Highest-risk content with very limited access	M&A, investigations, regulated data

Avoid labels that sound similar but behave differently unless users can clearly understand the distinction.

5. Decide which labels apply to files, sites, or both

Not every label needs every scope.

For example:

Label	File Label	Site/Group Label	Notes
Public	Yes	Yes	Useful for published or broadly accessible content
Internal	Yes	Yes	Common default for internal collaboration
Confidential	Yes	Yes	Useful for sensitive departments and files
Confidential - External Collaboration Allowed	Yes	Yes	Useful for vendor/client collaboration
Highly Confidential	Yes	Yes	Use for restricted workspaces and documents
Restricted	Yes	Maybe	May be better limited to files or special sites only

This decision should be based on how users collaborate.

6. Configure labels in Microsoft Purview

Labels are created and published through Microsoft Purview.

Admins should review settings such as:

• Label name
• User-facing description
• Admin description
• Scope
• Encryption settings
• Content marking settings
• Auto-labeling behavior
• Default labels
• Mandatory labeling requirements
• Label publishing policies
• User/group targeting

For file-level labels, be careful with encryption settings. Strong encryption can protect content, but it can also create support issues if configured too aggressively.

7. Enable SharePoint and OneDrive support carefully

Microsoft supports enabling sensitivity labels for Office files in SharePoint and OneDrive through Microsoft Purview or PowerShell depending on the scenario.

Before enabling broadly:

• Review Microsoft documentation
• Confirm licensing requirements
• Test in a pilot group
• Validate Office for the web behavior
• Validate desktop Office behavior
• Validate PDF behavior if relevant
• Confirm external sharing scenarios
• Confirm audit log visibility
• Prepare rollback or support guidance

Do not enable this in production without a pilot.

8. Test label behavior in real collaboration scenarios

Testing should include real SharePoint and OneDrive workflows.

Recommended test scenarios:

• Upload a labeled Word document to SharePoint
• Upload a labeled Excel file to OneDrive
• Open labeled documents in Office for the web
• Open labeled documents in desktop Office apps
• Share a labeled document internally
• Share a labeled document externally
• Apply a label manually
• Change a label
• Remove a label if permitted
• Test auto-labeling behavior
• Test co-authoring
• Test Teams file access
• Test access from unmanaged devices
• Test guest access

The purpose is to understand user impact before rollout.

9. Pilot with departments that understand the risk

Good pilot groups include:

• Legal
• HR
• Finance
• IT security
• Compliance
• Project management office
• Executive assistants

These teams often handle sensitive content and can provide useful feedback.

Do not start with the entire organization.

10. Monitor audit logs and user feedback

After pilot rollout, review:

• Label application events
• Label change events
• Label removal events
• Support tickets
• User confusion
• External sharing failures
• Files that are labeled incorrectly
• Sites with mismatched labels
• Business processes affected by encryption

Governance is not done after configuration. It requires monitoring and adjustment.

---

Recommended label strategy for SharePoint environments

For many organizations, a simple starting model is better than an overly complex one.

Here is a practical baseline:

Public

Use for content approved for public distribution.

Examples:

• Public brochures
• Published marketing content
• Public website files
• General public announcements

Recommended behavior:

• No encryption
• Clear user description
• Limited use in internal collaboration sites

Internal

Use for normal internal business content.

Examples:

• Process documents
• Internal meeting notes
• Department documentation
• Internal announcements

Recommended behavior:

• No encryption or light protection depending on requirements
• Consider as a default label for many users
• Keep user experience simple

Confidential

Use for sensitive business content.

Examples:

• Contracts
• Internal financial data
• Client project documentation
• Non-public planning documents

Recommended behavior:

• Consider encryption depending on business need
• Review external sharing behavior
• Consider DLP alignment
• Use for sensitive SharePoint sites and Teams

Confidential - External Collaboration Allowed

Use when sensitive content must be shared with approved external users.

Examples:

• Client project sites
• Vendor collaboration workspaces
• Partner delivery documentation

Recommended behavior:

• Allow external collaboration only under defined rules
• Use domain restrictions where possible
• Monitor guest access
• Review site ownership regularly

Highly Confidential

Use for content that requires strict control.

Examples:

• Payroll
• Legal investigations
• Executive strategy
• M&A planning
• Security documentation

Recommended behavior:

• Stronger encryption where appropriate
• Restricted sharing
• Limited site membership
• Review access frequently
• Monitor audit logs

Restricted

Use only for the most sensitive content.

Examples:

• Regulated data
• Investigation files
• Highly sensitive legal matters
• Board-level confidential material

Recommended behavior:

• Very limited access
• Strong encryption
• No broad sharing
• Strong review process
• Clear ownership

The best label strategy is one that users can understand and admins can support.

---

How sensitivity labels support Copilot readiness

Copilot readiness is not just about enabling a license.

It is about making sure Microsoft 365 content is secure, accurate, relevant, and properly governed before AI makes information easier to discover.

Sensitivity labels support Copilot readiness because they help organizations:

• Classify sensitive content
• Reduce unknown data exposure
• Identify confidential files and sites
• Apply stronger protection where needed
• Align DLP and governance policies
• Improve audit and reporting
• Create clearer data boundaries

However, labels are not a complete Copilot readiness strategy by themselves.

Organizations should also review:

• SharePoint permissions
• Overshared sites
• Inactive sites
• Stale content
• External sharing
• Guest users
• Search visibility
• Retention policies
• Data lifecycle
• Site ownership

Copilot can only be as safe as the content and permissions model underneath it.

For more on this topic, see my full SharePoint Copilot readiness checklist.

---

What SharePoint admins should document

A sensitivity label rollout should include documentation.

At minimum, document the following:

Label catalog

For each label, include:

• Label name
• Business meaning
• Scope
• Encryption behavior
• External sharing behavior
• Target users
• Example use cases
• Owner of the label
• Support notes

Site labeling rules

Document when to apply each label to:

• Communication sites
• Team sites
• Teams-connected sites
• Private channel sites
• Shared channel sites
• Project sites
• Department sites
• External collaboration sites

File labeling rules

Document when users should apply labels to:

• Word documents
• Excel files
• PowerPoint files
• PDFs
• Exported reports
• Client files
• HR documents
• Finance documents

Support process

Document how to handle:

• User cannot open labeled file
• External user cannot access file
• Wrong label applied
• User cannot remove label
• File labeled automatically
• Site has incorrect label
• Label blocks expected collaboration

Review schedule

Labels should be reviewed regularly.

Recommended review cadence:

• Monthly during pilot
• Quarterly after rollout
• After major organizational changes
• Before Copilot rollout
• Before compliance audits
• After external sharing policy changes

---

Final thoughts

Sensitivity labels are not just a compliance feature. For SharePoint and Microsoft 365 admins, they are becoming part of the practical governance conversation.

They help answer questions that permissions alone cannot answer:

• What kind of content is this?
• How sensitive is it?
• Should it be shared externally?
• Should it be encrypted?
• Should this workspace allow guests?
• Should this information be treated differently by governance and compliance policies?

The most successful sensitivity label rollouts are not the ones with the most labels. They are the ones where business users understand what the labels mean, admins understand how the labels behave, and governance teams can explain why the configuration exists.

For organizations preparing for Copilot, improving external sharing governance, or cleaning up SharePoint permissions, sensitivity labels should be part of the conversation.

If you are reviewing SharePoint governance, Microsoft 365 security, or Copilot readiness, feel free to review my portfolio and open-source SharePoint projects.

---

References

• Microsoft Learn: Enable sensitivity labels for files in SharePoint and OneDrive
• Microsoft Learn: Use sensitivity labels to protect collaborative workspaces
• Microsoft Learn: Learn about sensitivity labels
• Microsoft Learn: Create and configure sensitivity labels and their policies
• Microsoft Learn: Assign sensitivity labels to Microsoft 365 groups in Microsoft Entra ID