Use named entities in your data loss prevention policies
Read through Learn about named entities before you start to use them.
Tip
If you're not an E5 customer, use the 90-day Microsoft Purview solutions trial to explore how additional Purview capabilities can help your organization manage data security and compliance needs. Start now at the Microsoft Purview trials hub. Learn details about signing up and trial terms.
Before you begin
SKU/subscriptions licensing
For full licensing details see, the service description.
Permissions
The account you use to create and edit data loss prevention (DLP) policies, must have the DLP Compliance Management role permissions. For more information, see Add users or groups to a Microsoft Purview built-in role group.
Supported locations
You can use named entity SITs and enhanced policies to detect and protect sensitive items in these locations:
- SharePoint sites
- OneDrive accounts
- Teams chat and channel messages
- Devices (Windows 10/11 endpoint devices)
- Exchange mailboxes
- Instances
Named entity SITs and enhanced policies aren't supported for:
- On-premises repositories
- Power BI
Create and edit enhanced policies
To create or edit a DLP policy, use the procedures in Create and Deploy data loss prevention policies.
Workloads and services that support named entities
- Microsoft 365 eDiscovery supports the use of named entities in Substrate services.
- Instances supports the use of named entities in Microsoft Defender for Cloud Apps policies in the Defender for Cloud apps portal.
- Insider Risk Management supports the use of named entities in Substrate services.
- Records Management supports the use of named entities.
- Exact Data Match Sensitive Information Types supports the use of named entities.
Unified DLP
| Workload/Services | Support for Named Entities |
|---|---|
| Office Win32 clients policy tip | Not supported |
| Office WAC clients policy tip | Supported |
| OWA policy tip | Not supported |
| Outlook for Microsoft 365 policy tip | Supported |
| Endpoints (Windows 10, and 11 devices) | Supported |
| Exchange Transport rules | Supported |
| OneDrive for Business data-at-rest | Supported |
| SharePoint Online data-at-rest | Supported |
| Teams data-at-rest | Supported |
| Email messages data-at-rest | Supported for tenants with Privacy Service Plan |
| Instances |
Autolabeling
| Workload/Services | Support for Named Entities |
|---|---|
| Office Win32 clients offline | Supported, user must select label and manually apply |
| Online Office Win32 clients online | Supported with old confidence scheme |
| Outlook online | Supported with old confidence scheme |
| Office WAC client | Supported |
| OWA | Supported |
| Exchange transport | Supported |
| OneDrive for Business data-at-rest | Supported |
| SharePoint Online data-at-rest | Supported |
| Microsoft Purview Information Protection scanner | Not supported |
Known issues
| Issue | Impact |
|---|---|
| DLP Policy tips (OWA, Outlook, Office Win32 clients) | Policy tips with entity condition results in "no match" |
| Asian language support for person name (Chinese, Japanese, Korean) | Named entities supported for Latin-based character set only (that is, kanji isn't supported) for person name |
| On-premises repositories | Not supported as a workload |
| Power BI (preview) | Not supported |
Best practices for using named entity SITs
Here are some practices you can use when you create or edit a policy that uses a named entity SIT.
Use low instance counts (three to five) when you're looking for data that's in a spreadsheet and the keyword that's required by the SIT for that data is only in the column header. For example, let's say you're looking for US Social Security numbers, and the keyword
Social Security Numberonly occurs in the column header. Since the values (the corroborative evidence) are in the cells below, it's likely that only the first few instances would be in close enough proximity to the keyword to be detected.If you're using a named entity SIT, like All Full Names, to help find US Social Security numbers, use larger instance counts such as 10 or 50. Then, when both the person names and the SSNs are detected together, you're more likely to get true positives.
You can use Autolabeling simulations to test the accuracy of named entity SITs. Run a simulation using a named entity SIT to see what items match the policy. With this information, you can fine tune accuracy by adjusting the instance counts and confidence levels in your custom policies or the enhanced template conditions. You can iterate simulations until the accuracy is where you want it before deploying a DLP or autolabeling policy containing named entities in production. Here's an overview of the flow:
- Identify the SIT or combination of SITs you want to test in simulation mode, either custom or cloned and edited
- Identify or create a sensitivity label to be applied when the autolabeling policy finds a match in Exchange, SharePoint sites, or OneDrive accounts
- Create a sensitivity autolabeling policy that uses the SIT from step 1 and with same Conditions and Exceptions that are used in your DLP policy
- Run the policy simulation
- View the results
- Tune the SIT or policy and the instance count and confidence levels to reduce false positives.
- Repeat until you get the accuracy results you want