How to Create a DLP Policy in Microsoft Purview: Step-by-Step Guide

Start With the Policy Outcome, Not the Portal

To create a DLP policy in Microsoft Purview, open the Purview portal, go to Data Loss Prevention → Policies, select Create policy, choose a template or custom policy, configure its scope and rules, and submit it in simulation mode. That is the short answer. The work that determines whether the policy is useful happens before and after those clicks.

Begin with one sentence that a data owner can approve:

Prevent customer identity records from being shared with people outside the company, while allowing the approved customer-support workflow.

This sentence identifies the protected information, risky activity, affected destination, and required exception. “Protect personal data” does not. A vague objective produces a policy that is either too broad to enforce or too narrow to reduce risk.

Use this pre-build worksheet:

If these fields cannot be completed, pause the portal work. The broader DLP policy design and best practices guide helps convert a risk statement into a supportable control.

Check These 10 Items Before You Create the Policy

A policy can be configured correctly and still fail because its prerequisites are missing. Complete this list before building:

1. Confirm licensing for every user who benefits. DLP capabilities differ by location and entitlement. Standard Microsoft 365 DLP and advanced Endpoint, Teams, analytics, or AI scenarios do not share one universal license. Use the Purview E3 and E5 security-layer guide to frame the design, then verify current product terms.
2. Assign least-privilege administration. Use an appropriate Purview role group such as Data Loss Prevention or Information Protection rather than making the policy author a permanent Global Administrator.
3. Name a business owner. Security operates the control; a data or process owner decides which business activity is legitimate.
4. Verify the location prerequisites. Exchange, SharePoint, and OneDrive are service locations. Endpoint DLP requires supported devices to be onboarded and configured. On-premises repositories require the relevant scanner path.
5. Confirm the identities and groups are cloud-resolvable. Use current Microsoft Entra and Microsoft 365 groups supported by the selected location.
6. Validate the detector separately. Test built-in or custom sensitive information types against true-positive and negative samples. For authoritative identifiers, consider the Exact Data Match guide.
7. Document approved applications and destinations. A policy cannot distinguish “approved” from “unapproved” unless that distinction is represented in its conditions, actions, or endpoint settings.
8. Prepare user-facing wording. Write the policy tip, help URL, and escalation path before users see them.
9. Choose test content and test accounts. Include a positive sample, a near miss, a clean control file, an in-scope user, and an out-of-scope user.
10. Agree on rollback. The immediate rollback is normally to return the policy to simulation or turn it off while retaining evidence—not to delete it.

Microsoft’s DLP overview lists supported enterprise locations and explains that prerequisites vary. Treat the portal’s ability to show a location as an option, not proof that the tenant is ready to enforce there.

Create the Microsoft Purview DLP Policy Step by Step

Sign in to the Microsoft Purview portal with the approved administrative account, open Solutions → Data Loss Prevention → Policies, and select Create policy. Portal labels can change, but the decisions remain consistent with Microsoft’s create and deploy DLP policy guidance.

Step 1 — Choose the starting point. Select a regulatory or regional template only when its detectors and default behavior are close to the approved objective. Otherwise choose Custom. Open every template rule before submission; a template is Microsoft’s reusable starting logic, not your organization’s approved policy.

Step 2 — Name it for operations. Use a stable convention such as DLP-CustomerIdentity-ExternalSharing-Pilot-v1. Put the control objective, owner, ticket, and exception route in the description. Avoid names such as “New Policy 2” that become meaningless in alerts.

Step 3 — Select the administrative scope. If the tenant uses administrative units, decide whether the policy must be restricted to one unit. This controls who administrators can manage; it is distinct from choosing which users and locations the policy evaluates.

Step 4 — Choose locations deliberately. Enable only locations covered by the objective and ready for testing. Exchange email, SharePoint sites, OneDrive accounts, Teams chat and channel messages, devices, on-premises repositories, Fabric and Power BI, connected services, and Copilot-related locations have different conditions and actions. Do not select every location simply because the switches are available.

Step 5 — Include and exclude populations. Begin with a representative pilot group or named test locations. Exclude a group only when there is an approved business reason, owner, expiry date, and compensating control. Broad permanent exclusions are invisible holes in a security policy.

Step 6 — Create or edit the rules. A rule combines conditions, exceptions, actions, notifications, alerts, and priority. Build the smallest rule that expresses the control. Two understandable rules—one warning on low-volume sharing and one blocking high-volume sharing—are easier to investigate than one deeply nested rule.

Step 7 — Configure incident evidence. Choose alert thresholds and recipients that an operating team can actually review. A policy that creates thousands of unowned alerts is not monitored; it is merely noisy.

Step 8 — Select simulation. Choose Run the policy in simulation mode. Enable policy tips in simulation only when you intentionally want pilot users to see them. Do not select automatic activation after 15 days unless the owner has explicitly approved that change path.

Step 9 — Review and submit. Capture the policy name, configuration summary, approver, date, and change record. Submission starts evidence collection; it is not the end of deployment.

Build Rule Logic That an Investigator Can Explain

Read every DLP rule as a sentence:

When these conditions are true, unless this exception applies, take these actions, tell these people, and create an alert at this threshold.

Conditions identify content and context. They can include a sensitive information type, sensitivity label, trainable classifier, sharing state, recipient, file property, device activity, destination, or workload-specific signal. The current Microsoft DLP policy reference is essential because the condition and action catalogue changes by location.

Use confidence and occurrence counts to express risk. One loosely matched identifier in an internal document may justify audit. Ten high-confidence identities sent externally may justify a block. Where practical, use a sensitivity label design as stable business context rather than rebuilding classification through keywords in every policy.

Write exceptions narrowly. “Exclude Executives” is an identity-based bypass. “Allow the audited merger workspace for members of the transaction team until the closing date” is a bounded exception. Record an owner and expiry outside Purview because the portal cannot decide whether the business reason remains valid.

Rule order also matters when several rules can match. Keep priorities intentional, document overlap, and test combined behavior. Do not rely on “stop processing more rules” as proof of simulation behavior; Microsoft notes that this setting does not operate in simulation mode.

Make the Policy Tip Tell the User What to Do Next

A policy tip is part of the control, not decorative text. “This action is blocked by your organization” creates a support ticket. A useful message states what was detected in safe terms, why the action is restricted, and which approved route the user should take.

Use wording such as:

This file appears to contain customer identity information and cannot be shared through an external link. Share it through the approved Customer Exchange workspace. If this detection is incorrect, select Override, enter the business reason, and notify Data Protection.

Do not place the sensitive value itself in a notification, email subject, or help-desk ticket. Provide an internal help page, policy owner, and response expectation. If override is available, require a business justification and review it; otherwise the override becomes an unmonitored “continue” button.

When users report that an expected tip is missing, check the workload and action first. A SharePoint sharing event, an Outlook message, a Teams post, and a device upload do not use identical evaluation paths. Confirm the account, app, destination, policy mode, supported condition, and whether the exact activity has occurred before editing the detector.

Prove the Policy in Simulation Before You Enforce It

Open the policy after submission and select View simulation. Microsoft’s DLP simulation guidance exposes an overview, items for review, and alerts. Results are retained for the most recent 30 days. Exchange and Teams commonly evaluate when a message is sent, devices when a relevant transfer occurs, and SharePoint or OneDrive can also scan existing content at rest.

Run the planned test matrix, then review real production matches:

Sample across departments, file types, languages, recurring reports, templates, and service-generated content. A detector that works on five hand-built files is not yet proven against the data estate. Review the matched item, rule, user, location, activity, count, confidence, destination, and expected production action. Ask the data owner to classify representative results as true positive, false positive, or legitimate exception.

The decision gate is explicit: enforcement is approved only when the policy matches the stated risk, false positives are acceptable, required exceptions are bounded, support is prepared, and rollback is documented. The simulation-first deployment guide provides a deeper evidence model.

Move From Simulation to Enforcement in Controlled Stages

Do not move from tenant-wide simulation to tenant-wide hard blocking in one change. Use a progression that matches the risk:

1. Simulation without tips establishes baseline behavior and detector quality.
2. Simulation with tips validates the wording and gives pilot users a safe route.
3. Pilot enforcement applies the planned response to a representative group while support watches closely.
4. Wave deployment expands by department, region, or workload after each review.
5. Full enforcement occurs only when ownership, evidence, and operational capacity remain sound.

Before each wave, record the scope, start time, approver, expected match volume, support contact, monitoring window, and rollback trigger. Microsoft states that policies generally take effect about an hour after activation, but do not use that statement as a stopwatch across every workload. Confirm behavior through policy status, a controlled test, alerts, and Activity Explorer.

After enforcement, monitor blocks, warnings, overrides, justifications, affected users, destinations, help-desk cases, and business outcomes. A falling number of unsafe attempts can indicate that users learned the approved path. A rising override rate often means the rule conflicts with legitimate work or users discovered that justification has no consequence.

Material changes—new detectors, locations, actions, or populations—return to simulation. Keep a versioned record so an investigation can establish which logic was active when an event occurred.

What to Do When the Policy Does Not Behave as Expected

The policy has no matches. Confirm that submission succeeded and the policy is in simulation or enforcement. Verify the user, group, site, account, device, and activity are in scope. Recheck every condition, count, confidence level, and exception. Use a known positive sample and create a fresh supported activity; an existing file at rest and a newly shared file do not always follow the same timing. Then inspect simulation status and Activity Explorer.

The policy matches almost everything. Stop before enforcement. Identify which detector contributes the match, raise confidence or occurrence thresholds, add corroborating evidence, narrow the activity or external context, and replace broad keywords with a stronger signal. Review custom SIT false-positive reduction when a regular expression is involved.

The right content matches, but the wrong action occurs. Compare the selected location with the action supported there, rule priority, policy mode, override configuration, and any overlapping DLP policy. The same conceptual “block” can appear differently in Exchange, SharePoint, Office, Teams, and endpoint channels.

A pilot works, but another department fails. Compare licenses, group membership, administrative-unit boundaries, device onboarding, client or browser path, data formats, and destinations. Do not weaken the global rule until the difference is known.

A change is not visible yet. Preserve the existing policy and follow the DLP propagation troubleshooting guide. Check configuration acceptance, distribution, workload evaluation, and event visibility separately instead of repeatedly editing the policy and resetting the investigation.

A business process is blocked in production. Return the affected policy or rule to simulation, or narrow the pilot scope according to the approved rollback. Preserve the event and configuration evidence, restore the safe workflow, identify whether the result is a false positive or an undocumented legitimate exception, then obtain owner approval before redeployment.

Finish only when the policy can be operated

A complete policy has more than conditions and a block action. It has a named owner, traceable objective, verified entitlement, tested detector, bounded scope, intelligible user guidance, simulation evidence, approval record, alert route, support procedure, rollback plan, and review date.

Store those details in a policy register and review them after incidents, major business changes, new data sources, licensing changes, and scheduled control reviews. Retire policies that no longer serve a current requirement. Unowned rules accumulate exceptions and noise until nobody can explain their effect.

To build the surrounding knowledge, use our free cybersecurity courses, including the Microsoft Purview learning material. When the implementation is complete, validate practical understanding through the free cybersecurity exams. The goal is not to memorize a wizard. It is to make every DLP decision—from detection to enforcement—explainable, testable, and supportable.