Common mistakes you may be making with Data Loss Prevention
- welka2111
- Mar 14
- 26 min read
Updated: Mar 19
With Microsoft Purview’s "Secure by Default" initiative from the engineering team at Microsoft, creating Data Loss Prevention policies has become simpler and more efficient.
However, having the Microsoft documentation at hand, still does not give you enough knowledge to implement a comprehensive, gap free, easy ish to manage data loss prevention structure.
It is for this very reason that I have written up my tips on how to properly deploy, customise and manage Data Loss Prevention based on the common mistakes I see people make in Microsoft Purview.
Introduction
This post isn’t a step-by-step guide for implementing Data Loss Prevention; instead, it’s a collection of common mistakes and I often see people make when setting up their DLP policies and some implementation tips. These insights come from my own experience and real-world scenarios, so while they reflect what has worked (and sometimes hasn’t) for me, they might not align with everyone’s approach.
I’ve decided not to limit this post to a specific number of tips and mistakes, as DLP changes every single day, therefore over time more caveats might be added to this list.
Also, this post follows the ‘Common mistakes’ series, with the first part being “Common mistakes when implementing sensitivity labels”, which you can check out here.
Common mistakes I see people make in Microsoft Purview Data Loss Prevention, and tips how to remediate those issues:
Not planning ahead properly
Many organisations jump straight into deploying DLP without a solid strategy. This can result in a mess of poorly aligned policies. It’s crucial to plan thoroughly, taking into account what data is sensitive, the rules you need to follow, and how users will interact with the system. DLP needs to be both secure and user-friendly, so planning ahead can save a lot of headaches later.
Failing to classify data effectively You can’t protect sensitive data unless you know what it is. Without accurate data classification, your DLP efforts will be like trying to hit a moving target. Start by classifying data based on what’s critical for your business and legal compliance, then build your DLP policies around that foundation.
Ignoring the complexities of managing DLP policies The more data you have, the more paths it can travel through, and the more people need access to it. Managing all these permissions and restrictions is a full-time job, but it’s a job that never ends. As your organisation grows, so do the complexities. Keeping track of every new data access point is unrealistic and will only overwhelm your security team. This complexity can lead to the security team overcompensating – making it difficult for employees to transfer data without authorisation. Unfortunately, this means that some policies may generate a lot of false positives, which add an extra burden to the security team’s workload in the form of constant notifications – also known as “alert fatigue”.
Overcomplicating things with unnecessary restrictions While it’s tempting to lock everything down, too many restrictions can actually slow down employee productivity and result in workarounds. If employees can’t access or share the data they need, they’ll find ways around your policies. DLP needs to be secure but also flexible enough to allow users to do their job without hitting constant roadblocks.
Not keeping things context-aware Traditional DLP might catch obvious sensitive data like credit card numbers, but it’s not great at recognising the nuances of different business environments. A policy that works for one company might not be effective for another, and failing to customise policies based on your organisation’s context can lead to security gaps. Therefore, I wouldn't recommend using some of the built-in policy templates based around different categories and regulations, but instead set up custom policies.
Neglecting to consider the fact that DLP is meant to prevent accidental data sharing DLP should be viewed primarily as a means to prevent accidental data loss or deviations from approved business data flows, rather than as a foolproof method for preventing data leaks, given the existence of bypasses such as data obfuscation techniques or simply taking a photograph.
Not prioritising employee awareness and training User awareness campaigns and user training are crucial when implementing DLP for several reasons:
Users need to be aware of the DLP policies and procedures in place. Training helps them understand what is expected of them and how to comply with these policies. This reduces the risk of accidental data breaches.
Training helps users identify what constitutes sensitive data and why it needs to be protected. This awareness ensures that users handle sensitive information appropriately and avoid actions that could lead to data loss.
Many data breaches occur due to human error. By educating users on best practices and the importance of data protection, you can significantly reduce the likelihood of accidental data loss.
When users understand the importance of DLP and the potential consequences of non-compliance, they are more likely to follow the rules.
Regular training and awareness campaigns help build a culture of security within the organisation. When data protection becomes a shared responsibility, the overall security posture of the organisation is strengthened.
As DLP policies and technologies evolve, ongoing training ensures that users stay up-to-date with the latest practices and tools. This adaptability is crucial for maintaining effective data protection.
Failing to acknowledge the fact you will never get it right at first While you can develop a baseline policy that can be applied to most organisations, there is no such thing as a one-size-fits-all DLP structure. You won’t know what causes false positives or issues until you start testing. Also remember, it is about progress and not perfection. Take that crawl, walk and run approach and be flexible. Review and fine-tune policies as needed, as this is going to require a certain level of adaptability.
Not doing enough testing It's always a good idea to start by creating DLP policies in test mode. This approach allows you to check if the policy is correctly alerting via email (since nothing will appear in the DLP reports in audit mode by design) and helps you assess if the thresholds set for each rule are suitable. For instance, if you've set a rule to trigger when more than 5 credit card numbers are detected, testing might reveal that it's better to trigger the rule on just 1 credit card number. You can then adjust the rule accordingly and enable the policy to start populating alerts in the reports. Remember, it's often a process of trial and error, no matter how well you plan the implementation.
Not realising product limitations It’s easy to overlook the limitations of DLP on certain file types and devices. For example, DLP doesn’t support monitoring files like .exe, .dll, or .sys, and there are restrictions on scanning text in files beyond a certain size. Get to know these limitations upfront, so you’re not left in the dark when things don’t work as expected.
Key limitations and caveats:
No email redaction options within DLP.
Alerts are generated differently for emails compared to SharePoint or OneDrive items. In SharePoint and OneDrive, DLP scans both existing and new items, generating an alert whenever a match is found. In Exchange, only new email messages are scanned, and an alert is generated if there's a policy match. DLP doesn't scan or match previously existing email items stored in a mailbox or archive.
Max size of a DLP policy: 100 KB;
Policy name length limit: 64 characters.-Description length limit: 1,024 characters.
Policy rule length limit: 64 characters.
Max number of DLP rules: In a policy: Limited by the size of the policy; In a tenant: 600.
Max size of an individual DLP rule: 100 KB (102,400 characters).
Comment length limit: 1,024 characters.
Max size of an individual DLP rule: 100 KB (102,400 characters).
GIR evidence limit: 100, with each SIT evidence, in proportion to occurrence.
Max size of text that can be extracted from a file for scanning: The first 2 MB of extractable text.
Regex size limit for all matches predicted: 20 KB.
Endpoint DLP can't detect the label from another tenant in a document.
You can't monitor 'copy to clipboard' and enforce Endpoint DLP on Azure Virtual Desktop environments via browsers. However, the same egress operation will be monitored by Endpoint DLP for actions via Remote Desktop Session (RDP).
USB storage devices in virtualised environments are treated as network shares. You need to include the Copy to network share activity to monitor Copy to a USB device. All activity explorer events for virtual devices and incident alerts show the Copy to a network share activity for all copy to USB events.
References:
Not understanding the license requirements Before you dive in, make sure you’ve got the right licences. Microsoft 365 E3 or equivalent gets you basic DLP for Exchange, SharePoint, and OneDrive, while you’ll need E5 (or its equivalent) to get endpoint DLP, including for Teams. If you’re unsure, check out my guide on licensing. Link here: https://www.welkasworld.com/post/microsoft-purview-licensing-101
Unsure about which permissions are needed in Purview Policy deployment permissions
To create and deploy policies, your account must be part of one of these role groups:
- Compliance Administrator
- Compliance Data Administrator
- Information Protection
- Information Protection Admin
- Security Administrator
If In doubt, check out my blog post about Purview permissions here: https://www.welkasworld.com/post/microsoft-purview-permission-guide
Failing to onboard devices to endpoint DLP (eDLP) If devices aren’t properly onboarded into Microsoft Purview, your endpoint DLP won’t be able to track them. This is an easy step to overlook, but without it, you’re missing a significant part of your security strategy. This essentially means that you need to onboard your devices to Microsoft Defender for Endpoint (MDE) as Purview and MDE use the same service but two separate services. If you use 3rd party anti malware solution, you still need to onboard your devices to MDE, however you can use MDE in a passive mode. If you’re unsure how to do this, check out Microsoft’s official documentation: https://learn.microsoft.com/en-us/purview/endpoint-dlp-getting-started
Verifying policy sync to devices:
If you've created or edited a policy and want to check if it was deployed to your device, follow these steps:
Ensure the configuration status of your device is "Updated" in the Device Onboarding page. If not, set up the prerequisites until the status changes to "Updated".
You can download the MDE Client Analyzer (MDE Client Analyzer tool) tool to the Windows machine you need to investigate. Extract the contents and run the tool from an elevated command line to collect data for troubleshooting.
Not deploying the Microsoft Purview browser extension I recommend deploying the Microsoft Purview browser extension for non-native browsers like Google Chrome or Firefox to fully leverage the capabilities of Microsoft Information Protection, Data Loss Prevention, Insider Risk Management, Microsoft Defender for Cloud Apps, and Conditional Access. By deploying the extension, you gain additional control, such as the ability to block the upload of labelled files to unapproved cloud service domains.
For more information, you can refer to the official guide: Get started with the Microsoft Purview extension for Chrome.
Caveats:
For the Microsoft Purview Extension for Chrome to work, users need command access.
This extension is only applicable to Windows devices and isn't necessary for enforcing data loss prevention on macOS devices.
Microsoft Purview has recently upgraded the Purview Chrome extension to Manifest V3. If you already have the Purview Chrome extension installed, it should automatically upgrade to version 3.0.0.239 or higher.
Please note that Incognito mode isn't supported on both Google Chrome and Firefox and must be disabled.
Not leveraging Microsoft Information Protection scanner for on-prem repositories Deploying the Microsoft Information Protection Scanner (formerly AIP Scanner) helps discover and protect unstructured data on on-premises file servers and SharePoint Server. Failing to install the scanner reduces visibility over sensitive data in on-prem repositories and prevents the enforcement of data loss prevention measures.
Check the official Microsoft documentation for prerequisites, installation steps, and setup guidance.
The scanner operates in two modes:
Discovery mode – identifies sensitive data.
Classification mode – applies labels and protection based on policies.
Discovery data is stored locally in .csv format: %localappdata%\Microsoft\MSIP\Scanner\Reports\DetailedReport_%timestamp%.csv
Reference: https://learn.microsoft.com/en-us/purview/deploy-scanner
Neglecting the endpoint DLP (eDLP) settings Endpoint DLP requires a bit more than just basic configuration. Make sure you configure your endpoint DLP (eDLP) settings before you create policies scoped to your devices. Some of the key sub settings available include:
1. Advanced classification scanning and protection
Advanced classification scanning and protection let the Microsoft Purview cloud-based data classification service scan items, classify them, and send the results back to the local machine. This means you can use classification techniques like exact data match classification, trainable classifiers, credential classifiers, and named entities in your DLP policies.
Caveats:
The Paste to browser action doesn't support advanced classification.
Advanced classification is available for Office (Word, Excel, PowerPoint) and PDF file types.
DLP policy evaluation always happens in the cloud, even if user content isn't being sent.
To use advanced classification for Windows 10 devices, you need to install KB5016688. For Windows 11 devices, KB5016691 must be installed. Also, you need to enable advanced classification before Activity explorer will show contextual text for DLP rule-matched events.
2. File path exclusions for Windows
Just a note to say that there are Windows file paths excluded by default.
%SystemDrive%\Users*\AppData\Roaming
%SystemDrive%\Users*\AppData\Local\Temp
%SystemDrive%\Users*\AppData\Local\Microsoft\Windows\INetCache
File path exclusions for Mac
-macOS file paths excluded by default: /System
-Recommended file path exclusions for macOS: For performance reasons, Endpoint DLP includes a list of recommended file path exclusions for macOS devices. If the "Include recommended file path exclusions for Mac" toggle is set to On, the following paths are also excluded:
/Applications
/usr
/Library
/private
/opt
/Users/*/Library/Logs
/Users/*/Library/Containers
/Users/*/Library/Application Support
/Users/*/Library/Group Containers
/Users/*/Library/Caches
/Users/*/Library/Developer
It's recommended to leave this toggle set to On. However, you can stop excluding these paths by setting the toggle to Off.
4.Restricted app groups
Restricted app groups are collections of apps that you create in DLP settings and then add to a rule in a policy. Settings in a restricted app group override any restrictions set in the restricted apps list when they're in the same rule. So, if an app is on the restricted apps list and is also a member of a restricted apps group, the settings of the restricted apps group are applied.
5.Service domains
The service domains setting only applies to files uploaded using Microsoft Edge, or using instances of Google Chrome or Mozilla Firefox that have the Microsoft Purview Chrome Extension installed. When the service restriction mode is set to Allow, you must have at least one service domain configured before restrictions are enforced.
6.Always audit file activity for devices
By default, when devices are onboarded, activity for Office, PDF, and CSV files is automatically audited and available for review in activity explorer. Turn off this feature if you want this activity to be audited only when onboarded devices are included in an active policy. File activity is always audited for onboarded devices, regardless of whether they're included in an active policy.
Not enabling endpoint DLP for Windows Servers By default, Endpoint DLP isn’t enabled for Windows Servers when they’re first onboarded. To track DLP events in Activity Explorer, you must manually enable it. Once set up, the same DLP policies can apply to both Windows PCs and Windows Servers. Endpoint DLP supports Windows Server 2019 (KB5032196) and Windows Server 2022 (KB5032198).
You can enable this option in purview.microsoft.com > Settings > Data Loss Prevention > Endpoint DLP settings > Endpoint DLP support for onboarded servers (toggle to On).
Caveats:
Installing these updates disables the classification feature, meaning files won’t be classified on the server after installation. However, previously classified files will still be protected. To maintain security, install Microsoft Defender version 4.18.23100 (October 2023) or later.
Being unaware of endpoint DLP and just-in-time protection Just-in-time protection blocks all egress activities on monitored files until policy evaluation is complete. This applies to:
New files that haven't been evaluated.
Previously evaluated files that need re-evaluation due to updated cloud policies.
To use just-in-time protection, antimalware client version 4.18.23080 or later must be installed. If the client is outdated, disable just-in-time protection by installing one of these KB updates: Windows 10 – KB5032278 & Windows 11 – KB5032288.
It also supports macOS devices running the three latest major versions.
For users included in the scope, Endpoint DLP blocks all egress activities until policy evaluation finishes.
For users excluded from scope, Endpoint DLP only audits egress activities.
Fallback action in case of failure: this setting determines what enforcement mode DLP applies when policy evaluation doesn't complete. Regardless of the selected action, all relevant telemetry appears in Activity Explorer.
You can configure this option in purview.microsoft.com > Settings > Data Loss Prevention > Just-in-time protection
Unfamiliar with evidence collection on devices When investigating a Microsoft Purview DLP incident or troubleshooting a policy, it's useful to have a full copy of the file that triggered the policy. DLP can copy these files from onboarded Windows and macOS (preview) devices to an Azure storage account.
Only DLP investigators and admins with the right permissions can access these files from the Azure storage blob.
You can configure this option in purview.microsoft.com > Settings > Data Loss Prevention > Endpoint DLP settings > Setup evidence collection for file activities on devices
References:
Still using legacy Exchange DLPs Conditions targeting sensitive info types (SITs), data classifications, or sender override, and actions notifying sender, are deprecated as of November 2023 and should be replaced by Microsoft Purview DLP or alternatives. When you navigate over to the Exchange admin centre > Mail flow > Rules, you will be presented with a big yellow banner notifying you about this, like the one below.
I still to this day see customers who have Exchange DLP rules set up in their Exchange Transport Rules.
If you do have them in place, beside your rule name, you will see the below message:
Lacking clear policy and policy rule naming conventions
Lacking clear policy and policy rule naming conventions is problematic because, at the time of writing, you cannot rename a policy once it is created; you would need to delete it and set it up from scratch. Therefore, having well-planned naming conventions from the outset helps avoid unnecessary rework and ensures consistency.
I personally prefer to use something similar to the persona-based Conditional Access (reference: https://learn.microsoft.com/en-us/azure/architecture/guide/security/conditional-access-framework#naming-conventions)
So my policy names would look like the following:
DLP-Exchange-AllUsers-SharingGDPRInfo-BlockWithOverride
DLP-SharePoint-AllUsers-SharingGDPRInfo-BlockWithOverride
DLP-OneDrive-AllUsers-SharingGDPRInfo-Block
DLP-OnPrem-AllUsers-SharingGDPRInfo-Audit
Not aware of the DLP policy set up caching issues
Oh boy, where do I start with this…This issue arises when DLP policies and rules are not given unique names, leading to conflicts in the setup process.
What happens?
You create a DLP policy called "Test", with a rule named "Test1" inside it.
Later, you create another DLP policy and name it "Test1"
When adding a rule to this new policy (Test1), you again name it "Test1" (which already exists within the first policy called Test).
The DLP wizard won’t immediately warn you about the duplicate rule name.
However, when you try to submit the new policy, it will show an error, saying that a rule called "Test1" already exists.
If you rename the rule to "Test2" and try again, the original "Test1" policy (not the rule) has already been saved but without any rules inside.
When attempting to submit the policy again, the system will now tell you that a policy called "Test1" already exists.
You end up getting stuck in a loop where you need to be a couple of steps ahead. Also DLP policies cannot be renamed after creation.
How to fix it?
Since renaming DLP policies isn't possible, the only solutions are:
Cancel the entire wizard and go back to the original policy that was created but has no rules.
Exit the wizard, delete the incorrectly created policy, and start over.
How to avoid this issue?
Use clear naming conventions for both policies and rules to prevent duplicates.
Always double-check existing policy and rule names before creating new ones.
This issue can be frustrating, but proper naming practices can help avoid conflicts and unnecessary rework.
*I did notice that in some tenants, at the DLP rule stage, it shows you if you’re using a duplicate name, however this principle still applies.
Not using policies split by the workloads When creating DLP policies, consider separate policies per workload. For example, you might have a policy named “ExchangeOnline-Stop PII data sharing” and one named “SharePointOnline-Stop PII data sharing”. The reason for this is that when combining workloads, the DLP rules interface will only show conditions common to each workload chosen, which can lead to many options missing when incompatibilities occur. For example, conditions available for policies scoped to SharePoint and OneDrive are similar, while if we compare Exchange Online and devices, they are very different. Exchange Online workload has the highest number of conditions available to allow you extra granularity.
Not knowing how to properly protect files shared via Teams When setting up DLP policies for Teams, keep in mind that the "Teams" workload in the wizard only applies to chat and channel messages - not files. Files shared in Teams are actually stored in SharePoint Online or OneDrive for Business, so to ensure full protection, your policies should cover these as well. If you are setting up DLP policies for each workload, then it is fine because you’re covered. However, if you only want to protect messages and files shared on Teams, choose Teams, SharePoint and OneDrive as the locations.
Failing to utilise DLP for Microsoft 365 Copilot location (preview) Microsoft Purview DLP can prevent sensitive-labelled content from being used in Microsoft 365 Copilot (preview) responses. To do this, create a DLP policy using the Microsoft 365 Copilot (preview) policy location with the "Content contains > Sensitivity labels" condition.
What happens?
Blocked items still appear in citations, but their content won’t be used in Copilot responses.
Availability & coverage
Rollout is ongoing - it'll be available in your tenant when the rollout reaches you.
The Microsoft 365 Copilot (preview) policy location is only available in Custom policies.
When selected, all other policy locations for that rule are disabled.
Applies only to items in SharePoint and OneDrive.
Supported/ unsupported features
Microsoft 365 Copilot Chat – supported.
Word, Excel, PowerPoint – not fully implemented.
Example: If a labelled document is subject to a DLP policy, Copilot won’t summarise it in chat, but it might still summarise it on the page.
Admin Unit Support
Admin units aren’t supported for Copilot DLP policies.
Copilot runs in the user's security context, meaning users must already have access to an item before it appears in their prompt response.
Please note that any preview features are subject to change.
Underestimating the importance of policy and policy rule priority If you’ve got multiple DLP policies, and then multiple DLP rules within those policies, you need to understand how Purview decides which ones to apply.
For endpoints: when an item matches multiple DLP rules, DLP uses a complex algorithm to decide which actions to apply. Endpoint DLP applies the aggregate or sum of the most restrictive actions.
Policy priority order: when an item matches multiple policies with identical actions, the actions from the highest priority policy are applied.
Rule priority order: when an item matches multiple rules in a policy with identical actions, the actions from the highest priority rule are applied (therefore the least severe rules should be at the top).
Mode of the policy: when an item matches multiple policies with identical actions, the actions from all policies in the "Turn it on" state (enforce mode) are applied preferentially over policies in "Run the policy in simulation mode with policy tips" and "Run the policy in simulation mode" states.
Action: when an item matches multiple policies with different actions, the aggregate or sum of the most restrictive actions are applied.
Authorisation groups configuration: when an item matches multiple policies with different actions, the aggregate or sum of the most restrictive actions are applied.
Override options: when an item matches multiple policies with different override options, actions are applied in this order: No override > Allow override.
Not paying attention to condition order within a DLP rule
For Exchange and SharePoint workloads, when using the following conditions: 'content contains' and 'content is shared from Microsoft 365', and then also using an action ‘Restrict access or encrypt the content in Microsoft 365 locations’, you must add the ‘content is shared from Microsoft 365’ as the first condition, followed by ‘content contains’. Otherwise you are going to get the below message and you will need to go back and fix your rule. This is another scenario where you’re going to run into the wizard caching issue, I mentioned in mistake number 21.
Not using adaptive protection Adaptive Protection in Microsoft Purview combines Microsoft Purview Insider Risk Management with Microsoft Purview Data Loss Prevention (DLP). When insider risk identifies a user engaging in risky behaviour, they are dynamically assigned an insider risk level. Adaptive Protection can then automatically create a DLP policy to protect the organisation against the associated risky behaviour. As users' insider risk levels change in insider risk management, the DLP policies applied to them can adjust accordingly.
You can also manually create DLP policies to protect against risky behaviours identified by insider risk. Once Adaptive Protection is set up in insider risk, a condition called "User's risk level for Adaptive Protection" will be available for use in rules configured for policies scoped to Exchange Online, Devices, and Teams locations.
For Adaptive Protection to work on Devices, you must either enable Advanced classification scanning and protection or, if manually creating the Adaptive Protection policy, select the "File Type is" condition. If a user is targeted by both a default Adaptive Protection Device DLP policy and an independent Device DLP policy, only the actions of the most restrictive policy will be applied.
Neglecting to consider that Exchange DLP supports detecting sensitivity labels on emails and attachments Exchange DLP supports detecting sensitivity labels on emails (messages) and attachments, giving you finer control. You can choose to evaluate both, or only one: the message or the attachment.
You can also evaluate your rule per component.
Unfamiliar with the fact that you can use custom document property conditions in DLPs like ContentType crawled property
There’s a great article by the lovely Joanne C Klein that goes through a SharePoint content type DLP policy that explains this way better than I ever would, make sure you check it out: https://joannecklein.com/2023/03/11/a-sharepoint-content-type-dlp-policy/
Lack of understanding around low/medium/high levels of classifiers confidence in policy rules Classifiers used within rules can have high, medium, or low confidence levels. For example, a rule that triggers an alert for "2 credit card numbers with high confidence" means that Microsoft has determined with strong certainty that the data pattern matches the credit card classifier, and that there are exactly two credit card numbers in the file or email. On the other hand, a rule set to trigger for "2 credit card numbers with medium confidence" means that Microsoft is reasonably certain the data pattern corresponds to credit card numbers, but the confidence level is lower. Lower confidence levels increase the likelihood of false positives. It's important to note that confidence levels and the count of detected items are not the same, and you may want to create separate rules that focus on different confidence levels without overlap. For example, you could block an email if it contains 2 high-confidence credit card numbers but only issue a warning if it contains 2 medium-confidence credit card numbers.
I personally try to stick to high confidence only, whenever I can.
Not customising and leaving gaps within condition thresholds
Couple of rules of thumb when dealing with condition’s instance count. If you apply custom thresholds, for example 1 to 9 for a low severity alert, and then 10 to any, make sure you don’t leave any gap within the instance count but also don’t overlap numbers.
Correct scenario:
Low volume – instance count 1 to 9, High volume – instance count 10 to Any. Incorrect scenario:
Low volume – instance count 1 to 9, High volume – instance count 11 to Any.
Low volume – instance count 1 to 10, High volume – instance count 10 to Any.
Not naming groups within the rules
The more complex your rules are, and the more policies you have in place, the more you are going to need specific names for groups within the rules, so you can easily find the referenced area when you are troubleshooting DLP.
Unaware of options to include but also exclude conditions Using the NOT condition within a nested group can replace the functionality of Exceptions. This allows you more granularity for more complex rules. To use multiple operators, you need to create groups.
Not using AND, OR operators The DLP rule builder supports boolean logic (AND, OR, NOT). All existing Exceptions are replaced with a NOT condition within a nested group inside the Conditions. To use multiple operators, you need to create groups. The operators also allow for more granularity and flexibility.
Wrongly using nested groupings of conditions When you're creating a complex rule that combines multiple conditions and uses the AND or OR operators, as well as include and exclude groupings, it's crucial to ensure that all nested groups are configured correctly to work together. The Quick summary under Conditions provides a clearer view of the nestings and helps you check if they are grouped properly. A good rule of thumb is to look for the alignment of the grey outline to ensure your brackets and nestings are closed properly.
Ignoring group operators Make sure you’re using the appropriate group operators – ‘Any of these’ or ‘All of these’. Any of these is the default.
Not realising user notifications need to be enabled for OneDrive and SharePoint workloads
When scoping your DLP policy to OneDrive and SharePoint (both or separately), you need to have the user notifications enabled. If you don’t, you’re going to be presented with the below error.
This is also another example where you’re going to run into the wizard caching issue, I mentioned in mistake number 21.
Overusing user overrides (with business justification)
If a user frequently needs to override a block (nearly every time they are blocked), it may be best to exclude them from the policy.
Example: If you have a user within your finance department who sends out multiple invoices a day and you have a policy that blocks people from sharing financial information, for the finance user, this is a normal business operation, and bank information like an IBAN number or a SWIFT code would be present on every single invoice. In this case, it would be best to exclude them from the block policy. You can then perhaps set up a specific policy targeting the finance department, where the thresholds will be higher or where their activities are just audited, rather than blocked.
User overrides allow individuals to bypass DLP policy blocking actions on sensitive items in Exchange, SharePoint, OneDrive, or Teams, with justification, so they can continue their work. These overrides are enabled only when "Notify users in Office 365 services with a policy tip" is activated, meaning they work alongside Notifications and Policy tips.
User overrides are particularly useful when rolling out a new policy, as the feedback from override justifications and identifying false positives helps fine-tune the policy. If the policy tips in the most restrictive rule allow overrides, then overriding this rule also overrides any other rules the content matched.
Note that user overrides are not available for On-premises repositories. When a user overrides a block on an email, the override option and the provided text are stored in the Audit log and the email X-header. To view these business justification overrides, search the audit log for the ExceptionInfo value.
Unaware that DLP rule that will be used within Insider Risk Management policy needs to have a high severity incident report configured
Does what it says in the title, if you need to base your Insider Risk Management policy on an existing Data Loss Prevention policy, then your DLP rule(s) need to have the incident reports within them configured in a way where they generate High severity alerts.
Not knowing you can send email alert to a group Again, as it says on the tin, you can find it within a rule set up, you don’t have to select individual people, you can send it to a distribution group or similar.
Not realising you can remove the default SiteAdmin from notifications if it’s not needed This is something that is added by default but can be removed (which many people don’t know about or don’t care). However, you don’t necessarily want your Site Admins to see what sensitive info is being shared.
Not customising thresholds within incident reports
If your licensing plan permits, it's a good idea to use alerts based on volume thresholds instead of triggering an alert every time a rule is matched. This approach enables more targeted alert behaviour by focusing on instances where certain thresholds are exceeded or when the number of activities surpasses a specific count. This method is more likely to highlight genuinely suspicious behaviour and reduces the chances of alerts being dismissed as mere "noise."
Failing to make use of customisation of incident reports For incident reports, you should sometimes disable the bottom options 'the content that matches the rule, including the surrounding text' and 'the item containing the content that matched the rule' to avoid oversharing, especially if a SOC team or MSP is managing your alerts.
Not knowing you can stop processing more rules
As the name says, you can use the option to stop processing more rules. However, be aware of rule priorities and of the fact that stop processing more rules doesn’t work in simulation mode, even when it’s turned on.
Unaware of the concept of halting and non-halting Exchange DLP rules DLP policy rules in Exchange can be:
Non-halting – action is applied immediately, and processing continues to the next rule.
Halting – action stops further processing of other rules.
Example:
Halting action: "Restrict access or encrypt content in Microsoft 365 locations" – No further rules are processed.
Non-halting action: "Forward the message for approval to the sender’s manager" – Processing continues if the manager approves; if rejected, the rule becomes halting and blocks the email.
See the full list of supported Exchange DLP actions here: https://learn.microsoft.com/en-us/purview/dlp-policy-reference#supported-actions-exchange
Neglecting to consider that simulation mode only lasts 15 days Running a policy in simulation mode, for DLP policies replaces the old Test and Test with policy tips states. When a policy is in simulation mode, it operates as if it were being enforced, but without any actual enforcement. Unlike the Test modes, all matched items and alerts are reported in a separate dashboard. This makes it easy to see the policy's impact before enforcing it, as all simulation results are kept separate from the results of enforced policies.
Simulation mode offers:
An isolated environment to run and assess policies.
A summary dashboard that provides visibility into the policy's impact across different locations and shows which items were matched.
A flat list of matched items at the policy level.
Simulations can run for up to 15 days, so the results aren't just a snapshot in time.
For SharePoint Online and OneDrive for Business locations, all existing and new/changed items are evaluated.For Exchange, Teams, and Devices locations, only new items during the simulation are evaluated. Data from a simulation run is kept for 30 days.
If you need to have a policy in place that only audits user behaviour once conditions are met, and you want to have it in place for longer than 15 days, instead of setting up a policy in a simulation mode, you can set up a policy in an on mode, just configure your conditions, and leave your actions blank.
Unfamiliar with times to sync new policies
In general, policies take effect about an hour after being turned on.For groups changes, the policy needs up to 24 hours to sync, meaning that if you for example scope your Exchange Online policy to a distribution group called “Group A”, if you add a new member to that group, you’re expected to wait around 24 hours before DLP is enforced for that user.
Not acknowledging different experiences on different versions of apps
Aggghhh so many caveats to this that it really makes me want to scream sometimes. Essentially policy tips and DLP behave differently depending if someone is using classic Outlook, new Outlook, or Outlook on the web. Have a read below: https://learn.microsoft.com/en-us/purview/dlp-ol365-win32-policy-tipshttps://learn.microsoft.com/en-us/purview/dlp-owa-policy-tips
https://learn.microsoft.com/en-us/purview/dlp-policy-reference-new-outlook
Unaware of previous lack of support for DLP for Copilot agents by default
Up until January and February 2025, DLP policies didn’t automatically apply to Copilot Studio agent unless you explicitly enabled it via PowerShell. Reference link: Configure data loss prevention policies for agents - Microsoft Copilot Studio | Microsoft Learn
To manually enable it via PowerShell, run the below command let:
Lack of awareness around DLP policy tips and notifications for OneDrive and SharePoint
When a document in OneDrive or SharePoint matches a rule in a DLP policy with policy tips enabled, special icons appear:
Warning icon (red triangle): Shown when a rule sends a notification about the file.
Blocked icon (red stop sign): Shown when a rule blocks access to the document.
These icons often appear next to sensitive files that shouldn’t be shared externally. The two most common icons are:
-A round red icon with a hyphen (similar to a stop sign).
-An red triangle (warning indicator).
To check or take action on a flagged document:
1. Select the file.
2. Click Information in the upper-right corner.
3. View the policy tip in the details pane.
4. Depending on configuration, you may be able to choose Resolve, then either Override the policy tip or Report a false positive.
Why do these icons appear?
For example, say you apply a Confidential/Internal sensitivity label to a file and upload it to SharePoint. Even if you haven't shared it externally, you might still see an icon next to it. Possible reasons:
1. Proactive DLP warning – The system alerts you that the file shouldn't be shared or contains sensitive info.
2. Past external sharing – The file was shared externally at some point.
3. Inherited permissions – A folder or library that was previously shared externally might still grant access to external users.
Let’s say you upload a file named "Confidential File" to a Project Obsidian folder inside a Documents library.
Even if you haven’t shared it, a red icon appears.
This could mean that:
-The entire Project Obsidian folder was shared externally in the past.
-The Documents library itself was shared externally.
-External users still have access due to inherited permissions.
If DLP alerts are enabled, you may receive a notification like this, even if the file hasn’t actually been shared:
"This item is protected by a policy in your organization. It can't be shared with people outside your organization."
False positives and misleading alerts
Every time I talk about this, I feel like I’m opening a can of worms, as there are so many other cases where users receive false positive alerts, even when they haven’t violated any policy. DLP may still generate awareness-type policy tips (similar to those in Teams), which can be misleading.
Unfamiliar with the option wait on send dialog support for oversharing for Outlook When DLP policies are set up in Outlook and OWA, they evaluate messages for sensitive content and display policy tips.
The problem
Users can send an email before Outlook finishes evaluating content, meaning the DLP policy tip might not appear in time.
The solution
It is an option for you and your organisation to consider enabling "Wait on Send" by configuring the "Specify wait time to evaluate sensitivity content" setting in Cloud Policy via the Microsoft 365 apps admin center.
For a detailed setup guide, check out this awesome post by Tony Redmond: Configuring Outlook DLP Policy Tips Pop-Up Messages
Not using activity explorer to track DLP matches and DLP adoption Activity Explorer provides a view of DLP activities, including endpoint DLP activities, files containing sensitive info types, egress activities, and DLP policies and rules that detected activities. Without this tool, organisations may lack visibility into how their DLP policies are performing and where potential risks are occurring.
You can view the last 30 days of DLP information in Activity Explorer using these preconfigured filters or you can apply your own custom filters to look for information.
Not using Power Platform DLP Often being overlooked since the Power Platform DLP is managed separately to Microsoft 365 DLP and can be used to protect important assets.
Great article from Matthew Devaney on how to do it and Power Platform DLP policy best practices here: https://www.matthewdevaney.com/8-power-platform-dlp-policy-best-practices/
Disregarding Power Platform isolation By default, Power Platform cross-Entra tenant connections can be established: a user can connect from your tenant to a tenant they have provisioned themselves, a competitor's tenant, or an adversarial tenant. Then, for example, they could use Power Automate to automatically synchronise content such as files and communication to another tenant, performing data exfiltration. Tenant isolation allows you to control this in an allow-listed mode per external tenant. https://learn.microsoft.com/en-us/power-platform/admin/cross-tenant-restrictions
Not integrating DLP with other solutions Microsoft Purview DLP doesn’t live in isolation. Apart from the fact that you can utilise Microsoft Information Protection, including data classifiers and sensitivity labels in your policies or using your DLP policies within Insider Risk Management, you can integrate DLP with Microsoft Power Automate to trigger workflows based on DLP policies. Additionally, connecting non-Microsoft apps to Defender for Cloud Apps allows you to extend DLP protections to external services like Google Workspace, Salesforce, or Box.
Great content! Thank you very much!!!