.png){kind=logo}
Nathan Berger
Security Practice Lead, Cyclotron
As an enterprise-focused consulting team, Cyclotron’s Security Architects are frequently asked to demystify Microsoft Purview and its complex suite of products. If you’re new to the Purview branding, Microsoft Purview includes all the new & improved services in the Microsoft 365 compliance suite, plus some newer infrastructure protections for any cloud resources across Azure, AWS, GCP & more.
Consistently, Sensitivity Labels and DLP get intertwined in compliance discussions. Today, we’re demystifying how these tools work, how they differ and overlap, and when you should use each tool.
Clients often present us with scenarios like the following:
· We need to protect PCI within company storage.
· We need to prevent our source code from unauthorized access.
· We need to show compliance auditors that we prevent HIPAA data from leaving our tenant.
If you’re familiar with any modern compliance tools, the answer phrase “data loss prevention” (DLP) should be shouting in your head. DLP tools are perfect for protecting sensitive data to only those who should have access. Microsoft 365 Data Loss Prevention (docs) protects sensitive data workflows by governing sensitive data as it traverses the company boundary, across endpoints, file shares, Microsoft 365, and third-party storage.
But there’s another aspect of Purview that could work too, and sometimes better: Sensitivity Labels (docs), the file-level classification capability in Purview, can also apply automatic protections to sensitive data and prevent unauthorized access. These two technologies overlap significantly: Both can provide automatic protections for sensitive data based on content inspection, and both can prevent that access from unauthorized parties, whether internal or external.
Let’s take an example: A client presented us with that first scenario: "We need to protect PCI within cloud storage."
With DLP policies, this is a simple answer.
1. DLP policy:
· Rules: Block sharing of 1 or more Credit Card Number
· Audience: Prevent sharing outside the org (internal employees only)
· Locations: Exchange, SharePoint, OneDrive, Teams, Endpoints, etc.
· Override (optional): Allow but require business justification
With Sensitivity Label policies, this is also a straightforward answer.
1. Sensitivity Label
· Name: Employees Only
· Encryption: All company employees
2. Auto-apply Label policy:
· Rules: Automatically apply label at time of editing
· Encryption: Internal Employees only
· Locations: Exchange, SharePoint, OneDrive
· Override (optional for client-side): Allow but require business justification
Both approaches meet customer requirements but have different user experiences. The DLP policy results in sharing prevention at the application-level:
Images pulled from this Microsoft blog.
Meanwhile, a protected file with an Employees Only Label appears protected in the Office application like this:
And the recipient experience for non-employees opening the protected file will look like this:
Labels are effective, but the end-user recipient experience isn't very intuitive.
The DLP user experience is clearly better – it’s much simpler for end-users to understand why a file shouldn’t be shared, and recipients aren’t left confused at why they see an error message.
But the sensitivity label approach is arguably more secure: By protecting the file itself with permissions, that file can’t go anywhere without protection – even in the worst case scenario: If an attacker gained access to a laptop, copied those files and ransomed the computer contents, they still could not access the file unless they had a valid employee login at the time of opening (which would be shut down the moment a password reset occurs, rendering the file copy useless to them). In addition, users are constantly reminded via tooltip and label of appropriate use for that content.
To make things more confusing: These tools interact with each other, too. Sensitivity Labels can be used as conditions in DLP policies. For example, files labeled Confidential can be blocked from sending outside the org using a DLP policy. (Cyclotron generally won’t recommend that, as the core design of protection should rely on automated & accurate policy, not the somewhat-uncertain accuracy of end-user label choice.)
Here's a handy visual we created to highlight some of the differences between tools:
Note: this is a summary, but doesn't include nuance of some details above, like what "client-side" enforcement means. Also, these tools constantly gain new features, so measure this comparison over time.
In short, auto-applying sensitivity labels can often be more secure by using file-based protections, no matter where the content is used. This function is greatly extensible using file encryption settings, Conditional Access (on the old AIP app), Azure AD account blocking to prevent access, and built-in revocation in certain cases. Auto-labeling can introduce negative complexities too: Third-party apps can't read protected content unless they are "enlightened" by developers leveraging the MIP SDK. This will affect some app functionality, like previewing .docx files in Box, or block third-party apps on a device from using that file at all. Lastly, pre-defined encryption templates (like Employees Only) aren't as useful for auto-applying to email, as recipients outside the org may be confused why they can't open mail - and the sender might not realize mail was protected after being sent.
Meanwhile, DLP policies have a better end-user experience. Tooltips are always clear before content is sent. In addition, they cover more locations (Windows & MacOS endpoints, Teams, PowerBI); they generate alerts for admins to review incidents; and they are technically simpler than sensitivity labels to deploy to an enterprise, as there are less unexpected issues compared to file-level protections. But they aren't as secure as to prevent any unauthorized use of sensitive content, which labels are great for.
Both capabilities overlap with server-side protection & client-side protections, applying email encryption for outbound emails using RMS templates, allowing override (client-side only for labels), requiring business justification input from users, and supporting testing modes (Simulation Mode for labels, Test Mode for DLP policies).
We hope that helps clarify differences between tools, and the advantages and disadvantages of each. Both tools work well and are often used in combination to meet enterprise data protection requirements for our clients.
Cyclotron's Security Architects can help you design any Compliance use case using Microsoft Purview. If your organization needs to design its strategy & deploy Purview, reach out:
Nathan Berger
Security Practice Lead, Cyclotron