How to structure DLP policies so you can actually manage them

Most DLP deployments start the same way. Someone creates a policy called "Protect Sensitive Data", ticks every workload (Exchange, SharePoint, OneDrive, Teams, Devices), adds a handful of Sensitive Information Types, and turns it on.

It works for the first week. Then the alerts start rolling in and nobody can tell at a glance what triggered, where it triggered, or which team should be looking at it. The policy name tells you nothing. The rules are a mix of conditions for different workloads crammed into one place.

The real problem is that each workload has its own set of conditions and actions. When you target multiple workloads in a single policy, you only get the conditions and actions that are common to all of them. You lose access to the workload-specific options that make DLP actually useful.

Create separate policies for each workload: Exchange, SharePoint and OneDrive, Teams, and Devices (Endpoint DLP).

This is not just an organisational preference - it changes what you can configure. When a policy only targets Exchange, you get access to Exchange-specific conditions like "recipient is external" or "message contains attachment type". When a policy only targets Devices, you get endpoint-specific actions like "block copy to USB" or "block upload to cloud service".

If you lump all workloads together, these options disappear from the rule builder. You are left with the lowest common denominator.

Exchange - conditions for recipients, domains, attachment types, message headers. Actions for blocking, redirecting, encrypting.

SharePoint and OneDrive - conditions for sharing scope (internal, external, anyone links). Actions for restricting access, blocking sharing.

Teams - conditions for chat vs channel messages. Actions for blocking message delivery.

Devices - conditions for app type, browser, cloud service. Actions for block, audit, or warn on copy to USB, print, upload, clipboard, and more.

Within each workload, create separate policies per category of data you are protecting. Financial data, personally identifiable information, health records, intellectual property - whatever applies to your organisation.

So instead of one policy, you might end up with:

• DLP - Exchange - Financial Data
• DLP - Exchange - PII
• DLP - SharePoint - Financial Data
• DLP - SharePoint - PII
• DLP - Endpoint - Financial Data
• DLP - Endpoint - PII

This looks like more policies, and it is. But each one is small, focused, and easy to understand. When an alert fires from "DLP - Endpoint - Financial Data", you know instantly that someone tried to do something with financial data on their device. You do not need to open the alert, read through rules, and work backwards to figure out what happened.

The biggest benefit is not during setup - it is during day-to-day operations.

Alert triage becomes fast. The policy name tells you the workload and the data category before you even open the alert. You can route financial data alerts to the finance team and PII alerts to HR or privacy.

Tuning is safe. If your financial data policy on Exchange is too noisy, you can raise the instance count threshold without touching anything else. With a single broad policy, changing one threshold affects every workload and every data type.

Ownership is clear. You can assign policy owners per category. The person responsible for PII compliance owns all the PII policies. They can adjust rules, review alerts, and manage exceptions without needing to understand the financial data rules.

Reporting makes sense. DLP activity reports and alert dashboards break down by policy. If each policy covers a single workload and category, the reports are immediately useful without extra filtering.

Pick a consistent format and stick to it. Something like:

DLP - [Workload] - [Category] - [Optional: Region]

Examples:

• DLP - Exchange - Financial Data
• DLP - SharePoint - PII - UK
• DLP - Endpoint - Intellectual Property
• DLP - Teams - Health Records

The optional region suffix is useful for multinational organisations where GDPR rules differ from Australian Privacy Act rules, even though both involve PII.

Keep the naming convention documented somewhere your team can reference. New starters should be able to look at a policy name and understand exactly what it covers without opening it.

You do not need to rip everything out and start over. Migrate gradually:

1. Pick one information category - start with whatever generates the most alerts today.
2. Create the new workload-specific policies for that category in test mode.
3. Run them alongside the old policy for a couple of weeks. Compare what they catch.
4. Once you are confident, disable the rules for that category in the old broad policy and switch the new ones to enforce.
5. Repeat for the next category.

This way you are never flying blind. The old policy stays active until the new ones have proven themselves.