9.3 Create and Manage DLP Policies

The third DLP bullet on the July 28, 2026 outline is Create and manage data loss prevention policies. Design produced an intent statement. This section is the wizard, the four states, policy tips, and the incremental rollout Microsoft documents so you do not block payroll on day one. Adaptive Protection conditions, policy and rule precedence when several policies match the same item, and Defender for Cloud Apps file policies remain the next chapter — you will manage this policy's state without pretending you already ranked it against every other policy in the tenant.

Where you create the object

Sign in to the Microsoft Purview portal. Go to Data Loss Prevention > Policies and select Create policy (or + Create policy). Pick a template (Financial, Medical and health, Privacy, including enhanced templates such as U.S. Health Insurance Act (HIPAA) Enhanced) or Custom. Microsoft 365 Copilot and Copilot Chat is Custom only. Name the policy, choose administrative-unit versus full-directory scoping if you are unrestricted, turn locations on, then add one or more rules (conditions, actions, notifications, incident reports).

After you create a policy it lives in a central policy store and syncs to Exchange (and from there to Outlook and Outlook on the web), OneDrive, SharePoint, Office desktop apps, and Teams channels and chat. Microsoft's Learn about DLP article notes that policies generally take effect about an hour after they are turned on. Copilot DLP updates can take up to four hours. Do not treat "I clicked Submit" as "users are already blocked."

In preview, you can rename a policy or a rule. Existing activity explorer events, alerts, and audit records keep the old name until they age out. New records use the new name. That matters when a stem asks why last week's alert still shows "HIPAA draft" after you renamed the policy to "HIPAA production."

You can also create from Keep it off and come back. That is the documented development state, not a failed deployment.

The four states (simulation replaced Test)

Microsoft's simulation-mode article states that Run the policy in simulation mode replaces the older Test and Test with policy tips states. Learn the current labels; an answer that still says "set the policy to Test" is stale.

Simulation runs the policy as if it were enforced, without enforcing. Results land in a separate dashboard: simulation overview, items for review, and simulation alerts. Microsoft is explicit: while a policy is in simulation, those alerts do not show in the DLP alerts console and do not flow to the Microsoft Defender portal. If the item says "security operations never saw the alert in Defender," simulation is the reason — not a missing DLP Compliance Management role.

Other simulation facts you can quote:

• Stop processing more rules does not work in simulation, even when the switch is on. Do not tune rule-stop behavior from simulation data.
• Scan results displayed from simulation are saved for 30 days. You can leave simulation running longer; the console still shows only the most recent 30-day window.
• You may select Turn the policy on if it's not edited within fifteen days of the simulation so a quiet, untouched simulation can auto-enforce. Use that only when stakeholders agreed to a calendar, not as a default on a noisy HIPAA policy.
• After you leave simulation, insights can take up to 24 hours to disappear from the Overview page.
• Status strings you will see on the policy list include In simulation and In simulation with notifications.

You can switch a policy into or out of simulation after creation. State is not a create-time-only radio button.

When simulation is on and Show policy tips is off, a configured Block or Block with override behaves as Audit at runtime. When simulation is on and policy tips are shown, Block is applied as Block with override and Block with override stays Block with override. That is how Microsoft lets you educate without a hard block. Full Block without override waits until Turn it on right away. Deeper questions about which policy wins when two enforced policies match the same file are precedence — next chapter.

Three axes: state, actions, and scope

Microsoft tells you to manage deployment with three controls at once, and you can change any of them later.

Actions (least to most disruptive):

• Allow — Devices location only. The activity happens. You get audit data. No user notification, no alert from that action.
• Audit only — Activity happens. You can add notifications and alerts so people learn that the behavior is risky.
• Block with override — Blocked by default; the user can justify and continue. Overrides are a false-positive pipeline. For Exchange Online and SharePoint, configure overrides in the user notification section.
• Block — Blocked with no override. Still audit, still alert if you configured incident reports.

Start a new policy on Audit only (or Devices Allow) even if the long-term intent is Block. Change the action after simulation proves the SITs are right.

Scope uses each location's include/exclude. Default is all instances of a selected location. Simulation can be broad so you see surprise locations. Simulation with policy tips should shrink to a pilot distribution group. Turn it on widens to the intended production set. Devices are enforced only when both the user and the device are in scope; that pairing is easy to misconfigure and is not the same as Exchange's sender-group scoping.

Exchange versus SharePoint scanning: DLP scans new Exchange mail and alerts on matches. It does not scan existing items already sitting in a mailbox or archive. SharePoint and OneDrive scan existing items as well as new ones. A "why did this five-year-old email not alert?" question is Exchange behavior, not a broken policy.

Policy tips and user notifications

Policy tips are the in-app education surface: a pop-up or banner that the activity is risky, optionally with a custom text, a link to your policy page, and an override or "report false positive" control. Microsoft's planning guidance says to use tips before you move from simulation to restrictive modes so culture changes ahead of hard blocks.

Support is not universal. Microsoft's policy-tips reference is the matrix to remember at a high level:

• Outlook on the web, current Outlook for Microsoft 365, and new Outlook for Windows support tips; Outlook for Mac and Outlook mobile do not.
• SharePoint and OneDrive web support tips; the Win32 SharePoint/OneDrive clients do not.
• Word, Excel, and PowerPoint on the web support tips when the file lives in SharePoint or OneDrive and the policy is already stamped. Win32 Office apps only show tips for a subset of conditions — typically Content contains SITs, internal/external sharing, notify user, block everyone, and incident reports. Extra conditions (including many complex nested rules) mean no Win32 tip even though the service still enforces.
• Teams (web, desktop, mobile, Mac) shows tips on messages ("This message has been flagged"). No policy tips on files; the recipient may simply be denied access.
• Fabric and Power BI support policy tips and admin alerts (SITs except exact data match).
• Third-party cloud apps and on-premises repositories: no policy tips.

If the exam asks how to train users during rollout, the answer is simulation with policy tips plus notification email, scoped to a pilot, with a help URL — not Turn it on right away with Block and no tip.

Recommended rollout steps

1. Create the policy; state = Keep it off; stakeholder sign-off on the documented settings.
2. Switch to simulation (tips off). Scope can be wide. Watch the simulation overview and activity explorer. Tune SITs, instance counts, and exceptions (NOT groups).
3. Switch to simulation with policy tips. Narrow includes to a pilot. Collect user feedback. Build super-users.
4. Confirm control objectives are met and false positives are tolerable.
5. Turn it on right away for the designed locations. Monitor the DLP alerts dashboard (Purview keeps DLP alerts 30 days; they remain in Microsoft Defender for six months) and activity explorer. Investigate DLP rule matched and DLP rule undo events when content or thresholds change.

Incident reports on the rule are how production alerts are born. Simulation alerts are a dress rehearsal in a different room. Do not tell the SOC to hunt simulation matches in Defender.

Default policies may already exist (Office 365 DLP, Teams, devices, Copilot). You can edit them, but a designed HIPAA policy is still a new object you manage through these states rather than a surprise tenant default.

When you can walk a policy from Keep it off → simulation → simulation with tips on a pilot → Turn it on, and you know simulation alerts never join the production alert queues, you have this blueprint bullet. Ranking this policy against other matching policies, wiring Adaptive Protection, and writing MDCA file policies wait until the next chapter.