Compliance team / IT admins play a vital role in the organization to ensure the firm complies with business standards and industry regulations. When it comes to data, the detection and protection of data are among the most important tasks that any business has today.
With the help of Office DLP, it makes it easier to identify, monitor, and protect the sensitive data across:
- Microsoft 365 services such as Teams, Exchange, SharePoint, and OneDrive
- Office applications such as Word, Excel, and PowerPoint
- Windows 10, Windows 11 and macOS (Catalina 10.15 and higher) endpoints
- non-Microsoft cloud apps
- on-premises file shares and on-premises SharePoint.
Microsoft 365 DLP detects sensitive items by using deep content analysis, not by just a simple text scan. Content is analyzed for primary data matches to keywords, by the evaluation of regular expressions, by internal function validation, and by secondary data matches that are in proximity to the primary data match. Beyond that, DLP also uses machine learning algorithms and other methods to detect content that matches your DLP policies.
This article describes how to troubleshoot some common DLP issues.
Common Scenarios:
- DLP policy is not blocking sensitive information.
- DLP policy tips are not working in Outlook and OWA clients.
- DLP Policy False positive
.
Scenario 1: DLP policy is not blocking the sensitive information
Users are able to send emails/documents containing Sensitive Information like Credit Cards and SSN and items are not being blocked by the DLP policy.
Possible cause:
- Content of the email message.
- Configuration issue – DLP Policy
Possible Solution:
- Content of the email message
Check if the content of the message matches the format, pattern, and keywords as per Sensitive information type entity definitions - Microsoft 365 Compliance | Microsoft Docs
Example:
You can use Test-Message commandlet to investigate the issues related to the processing of the Exchange Transport Rules (ETRs) and Unified DLP rules.
Test-Message is used to send test email messages into the actual ETR/DLP pipeline to simulate real behavior and provides admins with an immediate evaluation report showing the match/didn't match rule results for a particular message.
To run Test-Message in PowerShell, admins need to specify:
- Sender address
- Recipients (array - You can specify multiple email addresses separated by comma)
- SendReportTo (mail address where you want to receive the evaluation report). Remember: messages are not delivered to the recipients, only to the defined SendReportTo alias.
- MessageFileData (optional, you can use a .msg/.eml file to generate a message that will be sent by Test-Message or you can run Test-Message without it and then the default message will be generated and sent)
- A flag that specifies which rules we are going to test and what kind of report we are going to receive: for ETRs it's -TransportRules, for DLP it’s -UnifiedDLPRules
Example :
$data = [System.IO.File]::ReadAllBytes('C:\Data\test.eml')
Test-Message -MessageFileData $data -Sender megan@contoso.com -Recipients adele@contoso.com -SendReportTo admin@contoso.com -UnifiedDlpRules
Please refer Test-Message (ExchangePowerShell) | Microsoft Learn for more information.
Sample Output:
Evaluating rule 68007c5e-37e0-4e81-9b8b-2a9b7e3c5341.
Scanning for sensitive types: 50842eb7-edc8-4019-85dd-5a5c1f2bb085,a2ce32a8-f935-4bb6-8e96-2a5157672e2c,cb353f78-2b72-4c3c-8827-92ebe4f69fdf,e55e2a32-f92d-4985-a35d-a0b269eb687b,a44669fe-0d48-453d-a9b1-2cc83f2cba77,178ec42a-18b4-47cc-85c7-d62c92fd67f8.
Discovered sensitive types: 'Credit Card Number' (count: 1, unique count: 1, confidence: 85).
Filtering results retrieved.
Text extraction data available from earlier attempt on same message. Skipping text extraction.
Filtering results retrieved.
Text Matched for for discovered data classification: 4111 1111 1111 1111.
Filtering results retrieved.
Text extraction data available from earlier attempt on same message. Skipping text extraction.
Filtering results retrieved.
Text extraction detected 0 attachments.
Text extraction detected metadata: , Coauth: False.
Discovered labels in attachment: .
Evaluating actions for rule 68007c5e-37e0-4e81-9b8b-2a9b7e3c5341.
Stamp rule history on message header.
Rule 68007c5e-37e0-4e81-9b8b-2a9b7e3c5341 evaluation resulted in a match.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match with Confidential properties.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match.
Exit policy rule evaluation. Continue to next.
Evaluating rule b068860b-7f53-477e-9385-c062d4f75438.
Scanning for sensitive types: .
Evaluating actions for rule b068860b-7f53-477e-9385-c062d4f75438.
Stamp rule history on message header.
Rule b068860b-7f53-477e-9385-c062d4f75438 evaluation resulted in a match.
Predicate ExEqualPredicate evaluation resulted in a match with megan@contoso.com properties.
Predicate ExEqualPredicate evaluation resulted in a match with IncludeExternalUsers properties.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match with 50842eb7-edc8-4019-85dd-5a5c1f2bb085 properties.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match with Credit Card Number properties.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match with Message Body properties.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match.
Predicate AndCondition evaluation resulted in a match.
Action NotifyUser was executed.
Exit policy rule evaluation. Continue to next.
Evaluating rule c10ed108-acad-4aed-b6e2-83954949e078.
Scanning for sensitive types: .
Evaluating actions for rule c10ed108-acad-4aed-b6e2-83954949e078.
Stamp rule history on message header.
Rule c10ed108-acad-4aed-b6e2-83954949e078 evaluation resulted in a match.
Predicate ExEqualPredicate evaluation resulted in a match with megan@contoso.com properties.
Predicate ExEqualPredicate evaluation resulted in a match with IncludeExternalUsers properties.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match with 50842eb7-edc8-4019-85dd-5a5c1f2bb085 properties.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match with Credit Card Number properties.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match with Message Body properties.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match.
Predicate ExContentContainsSensitiveInformationPredicate evaluation resulted in a match.
Predicate AndCondition evaluation resulted in a match.
Action NotifyUser was executed.
Action GenerateAlert was executed.
Action GenerateIncidentReport was executed.
You can upload a file to test whether these sensitive info types detect the matching elements you specified.
- In the Microsoft 365 compliance center, locate Data Classification in the left pane.
- On the Sensitive info types tab, select the one which you would like to test. Click on Test and upload the file
Test results include a Confidence level and Support elements as below
- In the Microsoft 365 compliance center, locate Data loss prevention in the left pane.
- On the Policies tab, select the policy that requires editing, and then select Edit policy.
- Review the policy settings and make necessary changes
Learn more about Fundamental parts of a sensitive information type and confidence levels Learn about sensitive information types - Microsoft 365 Compliance | Microsoft Docs
Create, test, and tune a DLP policy: Create, test, and tune a DLP policy - Microsoft 365 Compliance | Microsoft Docs
Supported DLP Conditions: Data Loss Prevention policy reference - Microsoft 365 Compliance | Microsoft Docs
Scenario 2: DLP policy tips are not working in Outlook / OWA client
DLP is not detecting the sensitive information and the policy tips are not shown in Outlook / OWA clients. The DLP function to evaluate the message isn't triggered immediately. When a message is created, it doesn't yet meet the DLP policy conditions. The DLP policy tip is called and the content is evaluated after data is added to the message. Wait about 30-50 seconds to let the function be called. You can also expect the function to occur automatically when one of the following actions occurs:
- An attachment is added or removed.
- AutoSave runs (one time every minute).
- You click Save (to manually save a message).
- You open a draft.
After the function is triggered, you receive a message that resembles the following if the message violates the DLP policies.
Possible Cause:
- Outlook Licenses
- Client-side issue.
- DLP Policy Configuration.
Troubleshooting:
- Outlook Licenses that support DLP policy tips: Outlook license requirements for Exchange features (microsoft.com)
- Make sure MailTips Options are enabled in the Client.
Steps: Outlook > File > Options > Mail > MailTips Options
- This issue may occur because the compatible version criteria that are processed by the policy evaluator are based on the version of mso20win32client.dll, not the version of Outlook. In many cases, the version of mso20win32client.dll is not the same as the version of Outlook and Office. Make sure that Outlook applies all expected DLP policies, the administrator must verify that the Policy Nudge Rule for minRequiredVersion has a value that's no greater than the client-installed version of mso20win32client.dll. Please refer to DLP Policy Tip notifications are not displayed in Outlook for Windows - Outlook | Microsoft Docs
- This problem occurs if the updated DLP policy wasn't downloaded to Outlook. Outlook Client checks for changes to DLP policies one time every 24 hours.
To work around this issue, force Outlook Client to download the updated DLP policies. To do this, you must use Registry Editor to remove existing DLP policies that are applied to Outlook Client. To do this, follow these steps:
- Exit Outlook Client
- Click Start, click Run, type regedit, and then click OK.
- In Registry Editor, locate the following subkey: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Outlook\PolicyNudges (For Outlook 2016 - HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\PolicyNudges)
- Delete the LastDownloadTimesPerAccount registry entry.
- Exit Registry Editor.
Now start Outlook 2013 again, create a new message, and then type some text. When you do this, you force Outlook 2013 to download DLP policies. For more information: Changes to a data loss prevention policy don't take effect in Outlook 2013 in Office 365 - Office 365 | Microsoft Docs
- This issue can occur if the DLP policy is configured in both EXO & Security and Compliance Center. Make sure the DLP policy is configured in one of the locations. Read more here: Office 365 DLP policy tips are not showing in Outlook or OWA - Office 365 | Microsoft Docs
- Policy configurations are not supported (Outlook 2013 and later clients only
Currently, Outlook 2013 and later supports showing policy tips only for these conditions:
- Content contains
- Content is shared
Currently, Outlook 2013 and later supports showing policy tips only for this action:
- Block people from receiving email messages or accessing shared SharePoint, OneDrive, and Teams files.
Note: Exceptions are considered conditions and all these conditions work in Outlook. They will match content and enforce protective actions on content. However, showing policy tips is not yet supported.
- One of the tools that can be used to troubleshoot DLP policy tips issue is Fiddler Trace. Please refer for more information: Troubleshooting Data Loss Prevention (DLP) policy tips - Office 365 | Microsoft Docs
Scenario 3: DLP Policy False positive:
DLP policy triggers incorrectly on content in messages or files. For example, numbers are mistaken for a Credit Card or Bank Account number.
Possible Cause:
- DLP Policy Configuration
- Content of the message
Troubleshooting:
It is always important for the administrators to test and tune the DLP policies before turning on for all the users in the Organisation.
- Make sure the content of the message matches the format, pattern, and keywords as per Sensitive information type entity definitions - Microsoft 365 Compliance | Microsoft Docs
- Investigate DLP False-positive using Incident report.
Generate an incident report action to the existing DLP policy
- In the Microsoft 365 compliance center, locate Data loss prevention in the left pane.
- On the Policies tab, select the policy that requires editing, and then select Edit policy.
- Review the Incident Report to determine why the rule is triggered. Below is a sample incident report that was generated
DLP false positives and overrides: If your DLP policy allows users to override it or report a false positive, this report shows a count of such instances over time. You can filter the report by date, location, or policy. You can use this report to:
- Tune or refine your DLP policies by seeing which policies incur a high number of false positives.
- View the justifications submitted by users when they resolve a policy tip by overriding the policy.
- Discover where DLP policies conflict with valid business processes by incurring a high number of user overrides.
All DLP reports can show data from the most recent four-month time period. The most recent data can take up to 24 hours to appear in the reports.
For more information, please refer to:
View the reports for data loss prevention - Microsoft 365 Compliance | Microsoft Docs