[Video] Making sense of Microsoft Purview sensitivity labels: Q&A with MVP Jasper Oosterveld

With security top of mind and AI now in the mix, it’s getting harder to keep sensitive information out of Copilot responses, guest inboxes, and the wrong hands. Microsoft MVP Jasper Oosterveld answers your burning questions about sensitivity labels in Microsoft Purview and how to use them to secure your M365 environment.

You’ve probably heard it all before when it comes to securing Microsoft 365: Enable this. Configure that. Apply labels here—oh, and make it Copilot-safe.

‍But how do you actually do all of that—without breaking stuff or drowning in complexity?

We teamed up with Jasper Oosterveld, Microsoft MVP and Data Security Consultant, to host a webinar on turning sensitivity labels in Microsoft 365 into one of your strongest tools for security, compliance, and Copilot readiness.

During our webinar, we had a lot of questions from our audience about managing sensitivity labels in real-life scenarios—like how to handle internal and external collaborators, what to do when generative AI tools like Copilot come into play, and how to ensure labels don’t disrupt productivity while still protecting sensitive data.

Check out Jasper's advice!

Q: What are Microsoft Purview sensitivity labels, and why should organizations use them?

A: You can use Microsoft Purview sensitivity labels for multiple use cases.

On one hand, they help you classify and protect data in Microsoft 365—like emails, Office documents, and even PDFs. When you apply a classification, you can also enforce protection using encryption. This helps prevent unauthorized access to your data.

On the other hand, sensitivity labels can be used to classify sites and teams. This supports your governance efforts by enforcing settings like external access or sharing restrictions.

And last but not least, sensitivity labels can also be applied to meetings. This allows you to enforce specific settings—like automatic recording or preventing users from copying sensitive information from the meeting chat.

Q: How are sensitivity labels applied — manually, automatically, or both — and what factors influence the right approach?

A: You can manually apply a label to an email, a document, or even a PDF. This is very easy to do. The downside—or rather, the challenge—is that not everyone always knows which label to apply in which situation.

If you’re working with sensitive information day to day, you’re probably aware that you need to apply a specific label that enforces protection.

But other employees might not always notice. That’s where automatic labeling can really help. You can detect sensitive information—like a passport number, medical data, or other information related to your organization—and then either apply a label automatically or recommend one.

This makes life easier for your employees and increases the success of your sensitivity label implementation.

How do sensitivity labels help organizations protect data in a world of hybrid collaboration and generative AI tools?

A: Sensitivity labels are incredibly powerful in these scenarios because, when you apply protection using encryption to an email or document, that protection stays with the file. So even if it leaves your Microsoft 365 environment, the encryption and protection still apply.

When it comes to AI tools, you can use, for example, endpoint Data Loss Prevention (DLP) to prevent the copy and paste of sensitive information into tools like ChatGPT or other external generative AI solutions.

There’s also a preview feature in DLP that allows you to prevent information with a specific sensitivity label from being processed by Copilot. This doesn’t mean the document is hidden—it simply ensures the labeled content isn’t used in prompt responses. That’s incredibly helpful. Just keep in mind: at the time of this recording, this feature is still in preview. So test it out with a few documents or users before rolling it out organization-wide. Wait until Microsoft makes it generally available.

Q: What’s the first step an organization should take when getting started with Microsoft Purview and sensitivity labels?

A: It all starts with policy. A key part of that policy is setting up your classification and protection guidelines.

For example, you might want to label documents or emails as "Public," "Internal," "Secret," or "Top Secret." That’s step one: define your classifications. Then, link protection settings to those labels. So, if something is classified as "Top Secret," you can automatically restrict access so only people within your organization can view it.

The second step is defining what counts as sensitive information in your organization. Maybe you deal with medical records. In that case, those records are your sensitive info—and you’ll need to decide what classification applies to them. From there, you can automatically apply a sensitivity label when that information is detected.

Q: When rolling out Microsoft 365 across the organization, should we implement sensitivity labels for each user group as they migrate, or wait until the full migration is complete?

A: Unfortunately, this is one of those “it depends” answers. It really depends on your migration timeline—like whether you’re working toward a deadline—and on your organization’s maturity level when it comes to compliance, risk, and Microsoft Purview.

In an ideal world, I’d recommend setting up your classification and protection policies, implementing sensitivity labels, and then using the Microsoft Purview information scanner to scan your local data for sensitive information. That way, you can apply the appropriate sensitivity labels before migrating the data.

If that’s not possible, then I’d recommend migrating everything first and applying the labels afterward. But ideally, you’d do it beforehand.

So that’s my advice—but again, there’s no one-size-fits-all solution. It really depends on your organization, your timeline, and your overall maturity level around compliance.

‍

New in ShareGate: Simplify sensitivity label migration in Microsoft 365

‍

Q: Can you change sensitivity label names once you create them? And can you remove sensitivity labels if they have been applied to any sites/files?

A: You can change the name—but only the display name. The field name (the name you provide the very first time you create the label) can’t be changed at this time. That’s not necessarily a problem, but it’s important to remember if you’re using PowerShell scripts or any coded solutions that reference the label. Just be aware that the display name and the field name might differ.

You can also remove a sensitivity label, but this can only be done by the:

• site owner
• team owner
• file owner

Removing a label can impact the security settings of the site, team, or file—so it’s something to be mindful of.

‍Q: How should we manage internal and external collaborators on the same project when using sensitivity labels?

A: If you're using sensitivity labels that block access to external collaborators, you need to make sure everyone—like those in the project team—is aware that when a certain label is applied, external collaborators will no longer have access.

So that’s something you’ll need to communicate clearly. You can also make your life a little easier by creating a private channel where files meant only for internal use are stored.

And you could use a default sensitivity label for that SharePoint document library to provide an extra level of protection for files that external collaborators shouldn’t access.

Q: How can we manage false positives in sensitivity label detection, especially for regulated data types like IP addresses or medical information?

A: This all comes down to testing. If the sensitive information types or trainable classifiers are set up to detect this kind of information, you need to test them with real data. Most of the time, there’s a test button. Upload the data and see if it gets detected.

If it doesn’t, you can tweak the sensitive information types. If it’s one provided by Microsoft, you’ll need to create a copy and adjust the detection settings from there.

But really, that’s what it comes down to—a lot of testing. And it’ll probably never be 100% perfect.

That’s also why it’s important to communicate with your organization. Make sure employees and colleagues are aware that false positives can happen, and that there’s a process for reporting it if a label is applied automatically in error.

Q: Does Microsoft Purview use OCR (optical character recognition) to detect sensitive information in scanned documents or image-based files?

A: Yes, it does—but not by default. You’ll need to manually activate the OCR feature in the Microsoft Purview admin center, and for that, you’ll need global admin permissions.

Once OCR is enabled, you’ll also need to connect an Azure subscription, since there's a cost associated with processing these files. It’s not overly expensive, but it’s something to be aware of.

Luckily, Microsoft provides clear documentation that walks you through the entire setup. If you have access to the settings menu in Purview, just go to the OCR section—you’ll find a direct link to the official Microsoft guide that explains how to configure and start using OCR.

Q: What Purview policies or controls should we implement to ensure Copilot doesn’t expose sensitive information through AI prompts or chat?

A: One of the options that’s currently in preview is a DLP policy that lets you prevent Copilot prompt responses from processing information in documents with a specific sensitivity label.

On the other hand, you could also use data loss prevention—and specifically, endpoint DLP—to prevent people from copying and pasting sensitive information.

You could also use communication compliance to monitor specific prompts and prompt responses related to sensitive information.

From there, you can create an automatic or manual reply to employees who enter that specific prompt—either alerting them that they’re using sensitive information, or even blocking it altogether.

‍

‍