Every control covered elsewhere in this cluster — identity, Conditional Access, Defender — governs access to systems and data. Microsoft Purview information protection (formerly discussed under the "Microsoft Information Protection" name) capabilities govern the data itself, following it as it moves between documents, emails, and applications, which matters because access control alone doesn't stop a legitimately-accessed file from being shared somewhere it shouldn't be.
Sensitivity labels
A sensitivity label is metadata applied to a document or email — Public, Internal, Confidential, Highly Confidential, or whatever taxonomy an organization defines — that can carry enforcement actions: encryption, watermarking, access restrictions, or a warning banner. Once applied, the label travels with the content even after it leaves the originating application, which is what makes labels more durable than access control lists alone.
| Enforcement Action | Effect |
|---|---|
| Encryption | Content readable only by authorized users/groups, even if the file is copied elsewhere |
| Access restrictions | Limits who can open, edit, or forward, independent of where the file is stored |
| Visual markings | Headers, footers, or watermarks indicating sensitivity to anyone viewing the content |
| Content marking + DLP trigger | Combines with data loss prevention policy to block or warn on risky sharing |
Auto-labeling reduces reliance on user judgment
Manually applying labels depends on every user correctly judging sensitivity every time — a reliability gap for genuinely sensitive content. Auto-labeling policies can apply a label automatically based on detected content patterns (a Social Security number format, a HIPAA-relevant term list), reducing that dependency for your highest-risk data categories specifically.
Labeling file types outside Office and PDF
Sensitivity labels are natively understood by the Office applications and PDF, where the label is written into the file's own metadata and travels with it. Organizations whose most sensitive material is not an Office document — engineering and CAD drawings, design files, research data, archives — hit a different model, and it is worth understanding before assuming labels solve the problem.
For file types without native support, the Purview Information Protection client applies what Microsoft calls generic protection: the file is encrypted and wrapped in a .pfile container rather than labeled in place. The protection is real — an unauthorized copy is unreadable — but the practical behavior differs in ways that matter operationally.
| Aspect | Native labeling | Generic protection |
|---|---|---|
| Typical file types | Word, Excel, PowerPoint, Outlook, PDF | CAD drawings, design files, archives, most other formats |
| Where the label lives | Inside the file's own metadata | In a wrapper around the encrypted file |
| Opening the file | Opens normally for authorized users | Client decrypts first, then the native application opens it |
| Content inspection / DLP matching | Available — policy can read inside the file | Not available — the contents are opaque to inspection |
| Auto-labeling on content patterns | Supported | Not supported; protection is applied by rule or by hand |
The consequence for a CAD or design workflow is that generic protection behaves like a secure container rather than a label: it protects the file at rest and in transit, but it inserts a decrypt step into how engineers actually open drawings, and DLP cannot inspect what is inside. Teams that try to apply the Office labeling model unchanged to an engineering file share usually discover this during rollout rather than during planning.
Where that friction is unacceptable, location-based controls generally carry more of the load than labels do — SharePoint and Teams site permissions, external sharing restrictions on the libraries holding drawings, and Conditional Access governing which devices can reach them at all. Labels and location controls are complementary here, not alternatives.
Confirm current file-type support before designing around it
Which extensions receive native versus generic treatment, and what the client supports on each platform, have changed across releases. Verify the current behavior against Microsoft's file-type documentation for your specific formats before committing to a labeling design — particularly for specialized engineering formats, where support is narrower than for mainstream file types.
Data loss prevention (DLP)
DLP policies detect sensitive content — based on pattern matching, sensitivity labels, or both — and take action when it's about to be shared inappropriately: blocking an external email containing unencrypted payment card numbers, warning a user before they share a labeled "Highly Confidential" file externally, or simply logging the event for review without blocking it.
- Start DLP policies in test/audit mode, exactly like Conditional Access and ASR rules — observe what would trigger before actually blocking anything, since overly broad pattern matching produces false positives that disrupt legitimate work.
- Scope initial policies to your highest-risk data categories (payment data, health information, credentials) rather than attempting comprehensive coverage immediately.
- Pair DLP with user education, since a DLP warning at the moment of a risky action is a genuine teaching opportunity, not just an enforcement mechanism.
How this connects to compliance frameworks
Data protection controls are directly relevant to several frameworks covered elsewhere in this Knowledge Center — HIPAA's Security Rule expects technical safeguards for electronic protected health information in transit and at rest, and DLP/sensitivity labels are a direct, auditable implementation of that expectation. See HIPAA Password Guidance for the broader HIPAA technical safeguards context this fits into.
Labels and DLP support compliance; they don't constitute it on their own
Sensitivity labels and DLP policies are strong technical controls, but — consistent with the same caveat given for Secure Score — they are one component of a compliance posture, not a complete compliance program by themselves. Confirm specific framework requirements with a qualified advisor.
Common mistakes
- Deploying DLP policies directly in blocking mode without an audit period, disrupting legitimate business workflows that happen to match overly broad detection patterns.
- Relying entirely on manual labeling for genuinely sensitive data categories, where auto-labeling would provide more reliable coverage.
- Treating labels as purely visual/informational without configuring the actual enforcement actions (encryption, access restriction) that provide real protection.
- Not training users on what a DLP warning means, causing it to be dismissed as a nuisance rather than understood as a real risk signal.
FAQ
Do sensitivity labels work across all Microsoft 365 applications? Broadly yes — Word, Excel, PowerPoint, Outlook, and Teams all support sensitivity labeling in current Microsoft 365 plans, though specific enforcement capabilities can vary by application and license tier.
Does encryption applied via a sensitivity label survive if the file is downloaded and moved to a personal device? Yes — this is the core value of label-based encryption over folder- or location-based access control: the protection travels with the file itself, not with where it's stored.
Is "Microsoft Information Protection" the same thing as Purview Information Protection? Yes — Microsoft Information Protection (MIP) is the former name for the capability set now delivered under Microsoft Purview. Sensitivity labels, labeling clients, and the underlying protection service are the same lineage; the branding changed, not the concept. Documentation, older configuration guidance, and many admin-side references still use the MIP name, so both terms describe the same thing in practice.
What happened to Azure Information Protection? Azure Information Protection (AIP) was the earlier product line, and its unified labeling capability was folded into this same Purview information protection stack. The AIP unified labeling client was retired in favor of built-in labeling in the Office applications and the Purview Information Protection client for other file types. If you are working from AIP-era documentation, expect the concepts to carry over but the specific client, portal location, and policy configuration steps to have moved.
What license tier includes Purview Information Protection and DLP? These capabilities are gated across different Microsoft 365 and Purview-specific licensing tiers, with more advanced auto-labeling and DLP capability typically requiring higher tiers — confirm current tier requirements directly with Microsoft, since packaging has changed over time.