Sensitivity Labels in SharePoint and OneDrive: A Practical Start

Sensitivity labels tend to go wrong when the rollout starts with naming and ends with wishful thinking.

For most SMEs, the first job is not to build a grand classification framework. It is to create a short label set that normal people can apply without needing a half-hour explanation.

Microsoft's current SharePoint and OneDrive labeling model is stronger than it used to be, but there is an important catch: if you want files in SharePoint and OneDrive to benefit properly, you need to enable sensitivity labels for those services. When that is in place, users can label supported files in the browser and Microsoft 365 can process encrypted files for coauthoring, search, DLP and eDiscovery in the supported scenarios. That is practical value, not just governance theatre.

Start with a label model people can remember

Start with four.

Label	Meaning	Example
Public	Safe outside the business	Website copy, public brochures
Internal	Normal business content	Process docs, internal notes
Confidential	Sensitive business data	Finance, HR, customer docs
Restricted	Highest-risk data	M&A, legal, privileged security docs

You can rename those to suit the tenant, but keep the model tight. The moment users need a decision tree, adoption drops.

Where labels genuinely help

Labels are worth doing when they change behaviour or control:

1. Mark sensitive files.
2. Apply encryption where needed.
3. Restrict external sharing for confidential data.
4. Help users make better decisions.
5. Support DLP policies.
6. Make review and audit work less argumentative.

Where labels do not save you

Labels will not fix chaotic permissions by themselves.

A confidential file in a site with broad membership is still broadly exposed. Labels and permissions have to work together, otherwise the label becomes a badge on top of the same old mess.

Another easy mistake is encrypting too much too early. If the pilot group spends the first week fighting document access and broken workflows, confidence disappears fast. Start with high-value use cases where the control is clearly justified.

A rollout plan that usually lands better

1. Agree label names and plain-English meanings.
2. Publish labels to a pilot group.
3. Enable sensitivity labels for SharePoint and OneDrive if they are not already enabled.
4. Label obvious sensitive libraries and documents first.
5. Train with real business examples, not generic security slides.
6. Add DLP and default library labels where they genuinely help.
7. Review what stayed unlabeled and why.
8. Expand in waves.

Good signs after the first phase

You should start to see:

• fewer arguments about what counts as sensitive
• clearer handling of HR, finance and customer data
• better support for DLP and sharing controls
• fewer "I did not know this should be protected" moments

That is enough for a first win. Perfect classification is not the target. Better decisions are.

If you are choosing between four labels that people will use and twelve labels that look clever in a workshop, choose the four and move on.

References

• Sensitivity labels in Microsoft Purview
• Enable sensitivity labels for files in SharePoint and OneDrive
• Configure a default sensitivity label for a SharePoint document library
• External sharing overview for SharePoint