Microsoft Purview Information Protection: What Actually Ships vs. What Demos

Every organization we walk into has a version of the same story. Someone bought E5 licenses, watched the Purview demo, declared that data classification was "handled," and then never touched the Compliance portal again. Months later, a security audit or an incident surfaces unprotected PII in SharePoint, and the sensitivity-label policy that was supposed to catch it has zero label coverage above ten percent.

Purview Information Protection is genuinely capable tooling. Getting it to production-useful, though, takes more than enabling the feature. This is what we have learned from deployments across regulated industries.

The Rebranding Confusion Is a Real Operational Problem

Before anything else: Microsoft has renamed this stack three times in five years. Azure Information Protection (AIP) became Microsoft Information Protection (MIP), which became part of Microsoft Purview. The PowerShell module is still AIPService. The unified labeling client installer still has "AIP" in the filename. Documentation articles on Microsoft Learn mix all three names depending on when they were last updated.

This matters operationally because you can have three different teams using three different names for the same control, and nobody realizes they are talking about the same policy. Align on one term internally. We use "Purview IP" or just "sensitivity labels" and stop there.

The other split worth knowing: there are two labeling clients. The built-in labeling client is baked into Microsoft 365 Apps (Word, Excel, Outlook, and so on) and is what Microsoft is actively investing in. The standalone AIP unified labeling client adds the right-click File Explorer experience and the on-premises scanner. If your estate is cloud-only M365, the built-in client is sufficient. If you have file servers or SharePoint on-premises, you need the scanner, which means the standalone client on the scanner host.

Label Taxonomy: Get This Wrong and You Repave It Later

The most expensive mistake we see is a taxonomy that mirrors org structure instead of data sensitivity. Labels named "Finance - Internal" or "HR - Confidential" force users to know the department context of every document they touch. That breaks down fast.

A flat four-level taxonomy works for most organizations:

• Public, approved for external distribution, no restrictions
• Internal, not for public disclosure, no encryption
• Confidential, encryption on, rights restricted to authenticated users
• Highly Confidential, encryption on, forward/copy/print disabled, expiry on external shares

Sublabels handle vertical variance: Confidential / PII, Confidential / Financial, and so on. Keep sublabels to a maximum of three per parent. Beyond that, users stop reading and start clicking the wrong thing.

Encryption on the Confidential tier is the threshold that separates real protection from a colored banner. Without encryption, a label is a metadata tag that any user can remove or ignore. With it, Purview's Rights Management Service enforces access even if a file lands in an uncontrolled location, including a personal OneDrive or an email attachment forwarded outside the tenant.

Auto-Labeling: Client-Side vs. Service-Side Are Not Interchangeable

Auto-labeling has two modes and Microsoft's documentation blurs the line between them.

Client-side auto-labeling runs in the Office application as a user types or opens a document. It detects sensitive information types (SSNs, credit card numbers, and custom regex patterns) and recommends or applies a label. The user can accept or override. Coverage is limited to documents opened in Office apps during the policy rollout window.

Service-side auto-labeling runs in Exchange, SharePoint, and OneDrive at rest and in transit. This is what actually covers your data lake. Policies scan content using the same sensitive information types but without any user in the loop. You configure simulation mode first, review what the policy would have labeled, tune the confidence thresholds, and then enable enforcement.

The confidence threshold is where most teams misconfigure this. The default is often set to "High confidence" to reduce false positives, which sounds right until you realize that a US SSN pattern at high confidence requires the presence of contextual keywords like "Social Security" within a certain character proximity. A spreadsheet column header of "ID" next to nine-digit numbers will miss. Run simulation mode for at least two weeks and pull the match report before you enforce.

KQL Detection: Labeling Telemetry Into Sentinel

If you have Microsoft Sentinel, label activity flows through the InformationProtectionLogs_CL table (when ingested via the Purview connector) or through CloudAppEvents if you have Defender for Cloud Apps. A detection worth running:

// Detect sensitivity label downgrade or removal, potential data exfiltration precursor
CloudAppEvents
| where Timestamp > ago(1d)
| where ActionType in ("FileLabelChanged", "FileLabelRemoved")
| extend OldLabel = tostring(RawEventData.OldSensitivityLabelId)
| extend NewLabel = tostring(RawEventData.NewSensitivityLabelId)
| extend Actor = AccountDisplayName
| extend FilePath = tostring(RawEventData.ObjectName)
| where isnotempty(OldLabel) and (isempty(NewLabel) or NewLabel != OldLabel)
// Prioritize: Highly Confidential -> anything lower
| join kind=leftouter (
    datatable(LabelId:string, LabelName:string)[
        "<your-hc-label-guid>", "Highly Confidential",
        "<your-conf-label-guid>", "Confidential"
    ]
) on $left.OldLabel == $right.LabelId
| where LabelName == "Highly Confidential"
| project Timestamp, Actor, FilePath, OldLabel, NewLabel, LabelName
| order by Timestamp desc

Replace the label GUIDs from your Purview compliance portal under Information Protection > Labels > right-click > Copy label ID. The same GUIDs appear in the MicrosoftPurviewInformationProtectionEventLogs table if you are ingesting that source directly.

Label downgrade is a low-volume, high-signal event. Someone removing Highly Confidential from a file before emailing it externally is worth a MEDIUM alert and a seven-day lookback correlation against that user's external email volume.

The On-Premises Scanner: What the Docs Skip

The Purview Information Protection scanner runs as a Windows service, connects back to the Purview portal via the scanner cluster registration, and crawls UNC file shares and SharePoint on-premises libraries. It writes label metadata to files directly (for supported types: Office documents, PDFs, images via OCR if licensed) and reports everything else as a discovery hit.

Two things we have hit on every scanner deployment:

First, the service account needs Log on as a service rights and write access to every share it labels. If you scope it read-only for discovery, it works. The moment you enable enforcement (write mode), share ACLs become a blocker. Plan the service account permissions before the scanner host is provisioned.

Second, scanner throughput on large file shares is slower than the documentation implies. Expect roughly 500,000 to 700,000 files per 24-hour scan cycle on a four-core VM with a local SQL Express instance. If you have tens of millions of files, you need multiple scanner nodes registered to the same cluster, each assigned non-overlapping repository paths. The cluster model is documented but the throughput math is buried in footnotes.

What Breaks in Production That the Demo Doesn't Show

A few patterns we have seen repeatedly across engagements:

Co-authoring and encryption do not mix cleanly for external guests. Encrypted documents require the guest to authenticate against your tenant's Rights Management Service. If the guest is on a consumer Microsoft account or a different federated IdP, the authentication flow often fails silently from their perspective. They just see "access denied" with no useful error. Design your external-sharing workflow around unencrypted Confidential labels or use sensitivity-label-protected links rather than encrypted files for external collaboration.

MIP SDK-protected files in third-party apps. If your users save Highly Confidential files and then try to open them in non-Microsoft tools (a PDF reader, a design app, a BI tool), the decryption will fail unless that application has integrated the MIP SDK. The list of supported third-party apps is shorter than you expect. Audit your application estate against the Microsoft Learn list of MIP-enabled applications before you expand encryption to high-volume workflows.

Label inheritance in Power BI. When a dataset in Power BI inherits a sensitivity label from its source SharePoint document library, the label propagates to reports built on that dataset. This is the behavior you want. The gotcha is that downstream exports (Excel, CSV) inherit the label and encryption from the report, which means users who previously exported freely will suddenly find their exports encrypted. Without user communication, this generates a wave of helpdesk tickets on the day you enforce.

Deployment Sequencing That Reduces Rollout Pain

We recommend a four-phase rollout:

1. Publish labels, no auto-labeling, no enforcement. Users see the label bar in Office apps. Collect baseline metrics on voluntary labeling rates for 30 days.
2. Enable client-side auto-labeling in recommend mode. Monitor accept/dismiss rates. Tune the patterns that generate high dismiss rates.
3. Enable service-side auto-labeling in simulation mode. Two-week window. Review the match report, set confidence thresholds, identify false-positive-heavy repositories.
4. Enforce service-side auto-labeling, deploy the scanner to on-premises repositories. Communicate the encryption behavior change to users who share externally before go-live.

Skipping straight to step four is how organizations end up with a rolling incident during rollout and a label policy that gets disabled by a frustrated IT admin.

For organizations working through this in a regulated context, our detection engineering practice covers the Sentinel integration side, and cloud architecture handles the identity and Rights Management Service design for multi-tenant environments.

When you are ready to move from demo to production-grade deployment, reach out to us and we can scope a Purview readiness assessment based on your M365 licensing tier and current data estate.