9.1 Design Data Loss Prevention Policies

The first DLP bullet on the July 28, 2026 SC-401 outline is Design data loss prevention policies based on an organization's requirements. Microsoft's design article (Learn: Design a data loss prevention policy) is blunt: document the policy before you open the wizard. A written policy intent statement is faster than trial-and-error clicks, and it is the artifact you reuse in stakeholder reviews, incident investigations, and later tuning.

Data loss prevention (DLP) in Microsoft Purview identifies, monitors, and automatically protects sensitive items. Detection is not a keyword grep. DLP uses primary matches (keywords, regular expressions, checksum-style function validation), secondary matches near the primary hit, machine learning, and, when you choose them, sensitivity labels or retention labels. Protective actions can warn with a policy tip, block sharing with or without override, lock or quarantine files at rest, or hide sensitive text in Teams chat. Those actions only make sense after you can say, in one sentence, why the policy exists.

The five questions every intent statement must answer

Microsoft's DLP configuration overview requires every policy to choose:

1. What to monitor (Office documents, email, device files, Copilot prompts, and so on).
2. Policy scoping — full directory versus administrative units (preview-era wording still appears as Policy scoping in the reference).
3. Where to monitor (locations).
4. Conditions that must match before the rule fires.
5. Actions when those conditions match.

If you cannot summarize those five answers in one statement, you are not ready to create the policy. Microsoft's own first-draft example is the HIPAA story you should be able to reconstruct on the exam:

"We're a U.S. based organization, and we need to detect Office documents that contain sensitive health care information covered by HIPAA that are stored in OneDrive/SharePoint and to protect against that information being shared in Teams chat and channel messages and restrict everyone from sharing them with unauthorized third parties."

That sentence is not marketing copy. It already names the template family (U.S. Health Insurance Act / HIPAA Enhanced), the locations (OneDrive, SharePoint, Teams), a sharing condition (people outside the organization), and an action (restrict access or encrypt content in Microsoft 365 locations). As you design, you will extend it with confidence levels, instance counts (leakage tolerance), include/exclude scopes, and whether the first production state is simulation or enforcement. The statement still stays one sentence plus a mapping table.

Map the statement to configuration

Work the mapping with stakeholders who own the business process, not only with security. The legal team can tell you which regulation applies; the process owner tells you who must still share the data. Microsoft's planning article uses internal auditors who export credit card numbers to a third-party auditor: a zero-leakage block would break that review unless you add an exception or a narrower action.

Locations change what you can configure. Microsoft's design article warns you to check the policy reference before you promise a sensitivity-label condition or a device-only action on a multi-location policy.

Locations you actually pick

Create DLP policies for Enterprise applications & devices in the Microsoft Purview portal. Microsoft's Learn about DLP article (updated 2026-06-26) lists these locations and sources: Exchange, SharePoint, OneDrive accounts, Teams chat and channel messages, Office apps (Word, Excel, PowerPoint), devices running Windows 10, Windows 11, and the three most recent macOS versions, non-Microsoft cloud apps, on-premises file shares and on-premises SharePoint, Microsoft Fabric and Power BI workspaces, Microsoft 365 Copilot and Copilot Chat (still labeled preview in that overview), and managed cloud apps. A separate Inline web traffic path (Edge for Business and Network Data Security, preview) targets unmanaged cloud apps; that is a different policy family, not a checkbox you add to a classic Exchange policy.

The policy-reference location table (the one you should memorize for include/exclude and administrative-unit support) currently documents:

Published scoping limits you should not invent beyond: Exchange policies support no more than 50 distribution-list / group inclusions and exclusions; OneDrive supports up to 100 individual users, or up to 50 groups if you need more people; SharePoint supports up to 100 specific sites. If you need more than 100 OneDrive users, put them in groups first. Mixing OneDrive users and groups in the same include list uses the intersection, not the union — User4 who is listed but not in the listed groups is dropped. Endpoint DLP device requirements, browser extensions, and endpoint settings are later chapters; this chapter only places Devices on the location list.

Combining locations shrinks the condition list

DLP can define content with a sensitive information type, a sensitivity label, or a retention label. Support is per location. SharePoint and OneDrive can use all three. Exchange can use SITs and sensitivity labels, not retention labels. Teams chat and channel messages can use SITs only. When you select multiple locations, Microsoft's rule is that a "no" takes precedence over a "yes." SharePoint plus Teams therefore becomes SIT-only even though SharePoint alone could have used labels. That is a design decision, not a portal bug.

Trainable classifiers are documented as a content condition for Exchange, SharePoint, OneDrive, Teams, Devices, and unmanaged cloud apps — not as a substitute for choosing the right locations.

Conditions, exceptions, and actions

A DLP policy is a container. The business logic lives in rules. A rule has conditions (what the item looks like and the context of the activity), actions (audit, notify, restrict, encrypt, quarantine, Copilot processing controls), user notifications / policy tips, optional user overrides, incident reports, and additional options such as rule priority. Conditions are where leakage tolerance lives: five Social Security numbers emailed outside the organization is a different rule from one SSN in an internal draft.

Context options change with location. Pick Exchange and you see sender/recipient predicates. Pick SharePoint and you see sharing and site context. Pick several locations and you keep only the conditions those locations share.

Exceptions as a separate designer surface are gone. Microsoft's design article states that existing exceptions are replaced with a NOT condition in a nested group inside Conditions. You create groups to combine AND, OR, and NOT. Example: block mail that contains credit card numbers or the Highly Confidential label, unless the sender is on the finance team and the recipient is a named mailbox. Nested NOT is the exception.

Office desktop trap: when Word, Outlook, Excel, or PowerPoint matches a policy that uses complex conditions, users see policy tips only for rules that use Content contains sensitive information. A beautifully nested label-or-SIT rule can enforce in the service and still look silent in the Win32 client.

Actions also follow location. SharePoint, Exchange, and OneDrive can restrict access or encrypt Microsoft 365 content and show a tip. Teams can block sensitive text in the chat. Devices can audit or restrict copy-to-USB and similar activities (Allow as an action exists only on Devices). On-premises repositories can move a file to a quarantine folder. You configure the action now even if the first state will be simulation — simulation is a deployment control, not a reason to leave the action blank.

Microsoft 365 Copilot and Copilot Chat

The dedicated Copilot DLP article (updated 2026-06-11) is the current behavior to study. The Microsoft 365 Copilot and Copilot Chat location exists, and it is only in the Custom policy template. Turning it on disables every other location on that policy. It does not support administrative units. DLP alerts, notifications, and simulation mode are supported. Policy updates can take up to four hours to show in Copilot.

You cannot put Content contains SITs and Content contains sensitivity labels in the same rule. Use two rules in the same policy. Documented actions under Prevent Copilot from processing content include blocking Processing prompts (no response; prompt not used for internal or web search), blocking Performing Web Searches (response still generated from permitted internal Microsoft 365 sources), excluding labeled files and emails from grounding (citations may still list the item), and, in preview, excluding Email is received from > External users using sender-domain metadata only. DLP does not scan the contents of files users upload into a prompt; it evaluates typed prompt text.

What this chapter does not design

Three neighboring blueprint skills are real and they are the next chapter: DLP for Adaptive Protection (Insider Risk Management risk levels as a condition), policy and rule precedence (including how multiple matching policies combine actions), and Defender for Cloud Apps file policies that use DLP. Do not stuff those controls into the intent statement yet. Mention them in the design review as follow-on work so stakeholders do not think one HIPAA policy also scores insider risk or replaces an MDCA file policy.

Design process you should be able to recite

1. Finish planning: stakeholders, categories of sensitive information, goals, deployment plan.
2. Read the policy reference so every component's effect is known.
3. Review what the DLP templates already include before you build Custom.
4. Write the intent statement with the process owner.
5. Place the policy in the overall DLP strategy (one regulation, one location family, or one department — not one giant policy that tries to be all three).
6. Map each clause to a configuration control.
7. Choose predefined template or Custom (Copilot forces Custom).
8. Collect every setting the wizard will ask, including ones the first draft omitted.
9. Document the full setting list and get sign-off.
10. Create a draft policy (next section) and keep it Keep it off until that sign-off exists.

If the item gives you a regulation, a location, a sharing story, and a desired user experience, your job is to produce that intent sentence and the mapping — not to skip ahead to Adaptive Protection or MDCA.