Sensitivity Labels Are Not Metadata. They Are Access Control.
Why most label deployments disappoint, how encryption, rights, and markings actually work together, and what it takes to ship labels that enforce security without breaking collaboration.
This is the third part of my series on treating Microsoft Purview as a real security control. Part one made the case that Purview belongs in the security stack, not just the compliance binder. Part two covered building a minimal, risk based classification blueprint. Now comes the step where classification turns into enforcement: sensitivity labels.
And this is exactly where many deployments quietly fail. Not because the technology is broken, but because of one fundamental misunderstanding.
The mental model shift
Most organizations think about labels like this: “This file is labeled Confidential.” That is a statement about metadata. It describes the file, and it protects nothing.
The correct mental model is: “This file enforces rules because it is labeled Confidential.”
A sensitivity label is an access control decision that travels with the content. It determines who can open a document, who can forward or share it, and who can copy or print it. Technically, it does this by applying three things: encryption, rights and permissions, and enforcement rules. The chain is simple: label, then protection settings, then enforcement. Break any link in that chain and you are back to decoration.
This is Zero Trust applied to data, in line with NIST SP 800–207: protection follows the asset itself, independent of network, device, or storage location. It is also precisely what ISO/IEC 27001 Annex A asks for, which requires not only classifying information but labeling and handling it according to its protection needs. A label with real protection settings is the technical implementation of that requirement.
Three controls, not one
Most sensitivity label problems happen because three distinct mechanisms get mixed up:
- Encryption controls who can open the data at all. It protects content at rest and in transit, and it travels with the file wherever it goes.
- Rights control what authorized people can do once they are in: edit, copy, print, forward, save as. Rights are where collaboration is designed.
- Markings are visual indicators only: headers, footers, and watermarks. They inform humans. They stop nobody.
Two warnings deserve to be printed in bold in every design document. First, markings are not protection. A watermark that says “Confidential” has never prevented a single byte from leaving an organization. Second, encryption without a thought through rights design equals broken collaboration. Locking a file so tightly that legitimate coworkers, or even the file owner, cannot work with it does not improve security. It teaches users to route around your controls.
Labels do not live in isolation
The second underestimated truth: labels move, inherit, and collide.
A labeled file gets uploaded to SharePoint. A labeled email carries attachments with their own protection state. A Teams channel inherits its container label, which may say something different than the labels on the files inside it. An external partner suddenly cannot open a document that worked fine last week.
The root causes are almost always the same three: precedence between container labels and file labels, conflicts with external sharing settings, and label downgrade rules that either block legitimate changes or silently allow protection to be stripped.
And even the same label behaves differently depending on where the content lives. In Outlook it governs the email body and attachments. In OneDrive and SharePoint it interacts with files, links, and sharing settings. In Teams and Microsoft 365 Groups it operates at the container level and shapes membership and guest access. Labels are context aware, not uniform. The practical consequence: testing must cover all surfaces, not just the one where the label was designed.
The failure patterns you will actually see
When label deployments go wrong, the symptoms are remarkably consistent: users who cannot open their own files, external partners blocked unexpectedly, “Access Denied” errors after re-labeling, and forwarding restrictions that break an established business process.
None of these are product defects. All of them are design decisions that were never thought through or never tested. Which leads to the one rule I would put above all others: if you cannot explain why a label behaves a certain way, you should not deploy it.
Earn enforcement, do not assume it
The rollout pattern that works mirrors what I described for classification, and it rests on two pillars.
Get Tom Wechsler’s stories in your inbox
Join Medium for free to get updates from this writer.
First, run detection in audit mode before anything blocks. Build a DLP policy in audit only mode, connect it to your classification blueprint, and test it against realistic scenarios: credit card data in a document, bank details, a real email flow. Review the alerts, confirm that nothing is blocked, and tune until the signal is trustworthy. Trust the signal before you enforce the control.
Second, pilot the label itself. Create the label, configure encryption and rights deliberately, and publish it to a small pilot group rather than the whole organization. Then validate end to end: does the label appear in Outlook, does an encrypted email reach an external recipient and open correctly, does internal access behave as designed? Protection without prevention is the goal of this stage: prove the mechanics before you tighten them.
What else deserves attention in this phase
Beyond the mechanics, several factors decide whether labels become trusted infrastructure or a support ticket generator. From my perspective, these are the ones most often missed:
- Design rights around personas, not fear. Before configuring a single permission, write down two or three realistic collaboration scenarios per label: internal coworker, external auditor, managed partner. Least privilege means as much access as needed, not everything locked by default.
- Plan the recovery path. Encrypted content raises operational questions nobody asks until it is urgent: who holds super user rights for eDiscovery and departures, what happens when an employee leaves, how is content recovered? Define this before the first file is encrypted, not after.
- Prepare the helpdesk. The first “I cannot open my own file” ticket will arrive. Give support a short runbook covering the top five label symptoms and their causes. A prepared helpdesk protects the project’s reputation.
- Decide the external collaboration model up front. Guest access, B2B trust, and encrypted mail to non Microsoft recipients each behave differently. Test with a real external mailbox, including a consumer address, before the pilot expands.
- Watch the intersection with automation and AI. Encrypted content affects search, eDiscovery, and increasingly AI assistants that index your data. Verify that the services your business depends on can still do their job within the rights you assign.
- Version your label taxonomy like code. Changes to published labels ripple across every labeled item. Treat label changes as change management: documented, approved, tested in the pilot group first, consistent with the ISO/IEC 27001 change control expectations your auditors already know.
- Close the loop with monitoring. Label usage reports and DLP alerts tell you whether labels are applied, ignored, or downgraded. Feed this into the same review cadence you established for the classification blueprint. In NIST CSF terms, this is where Protect meets Detect.
The bottom line
Sensitivity labels are the moment your classification strategy either becomes real security or stays a colored ribbon on documents. The difference is not the license or the portal. It is design discipline: separating encryption, rights, and markings, understanding how labels move and inherit, testing every surface, and earning enforcement through audit mode and a pilot group.
A label whose behavior you can explain, defend, and support is a security control. Everything else is metadata with good intentions.
Have you rolled out sensitivity labels with encryption in production? What broke first, and what did you learn from it? I would love to hear your experience in the comments.
Kind regards, Tom Wechsler
Sources: AI was used for spell-checking. The content is taken from my own PowerPoint files and from Microsoft, NIST and other sources (see links):
