10.4 Data Loss Prevention

What DLP Detects and Where It Enforces

Data loss prevention (DLP) is the Microsoft Purview capability that stops sensitive information from being shared, leaked, or exposed inappropriately. Where classification identifies data and sensitivity labels protect a file, DLP watches actions — sending, sharing, copying, uploading — and intervenes when those actions would expose sensitive content. The exam keyword is prevent.

DLP detects sensitive content using the same classification building blocks from earlier in this chapter: sensitive information types, trainable classifiers, and sensitivity labels. So a DLP rule can say, in effect, "if a message contains a credit card number" (SIT), "or a document the Resume classifier matched" (trainable classifier), "or anything labeled Highly Confidential" (sensitivity label), then take an action.

The most important SC-900 fact is coverage: a single DLP policy can apply across many Microsoft 365 locations at once. The tested locations are:

This breadth is the point: an administrator authors one policy and Purview distributes it to all the selected enforcement points, so the same rule protects an email, a Teams chat, a SharePoint document, and a USB copy on a laptop.

Endpoint DLP, Actions, and Policy Tips

Endpoint DLP extends prevention from cloud services down to the physical device. It uses the Microsoft Purview agent integrated with Microsoft Defender for Endpoint to monitor file activity on Windows 10/11 and macOS machines and to block or audit risky actions such as copying a sensitive file to a USB drive, printing it, copying it to the clipboard, uploading it to an unallowed cloud service, or opening it in an unapproved app. This is why Endpoint DLP scenarios often mention Defender for Endpoint — the agent is shared.

When a rule matches, DLP can take graduated actions:

• Audit only — log the event for visibility without disrupting the user (good for tuning).
• Block — stop the action entirely (for example, prevent the email from being sent externally).
• Block with override — block but let the user justify and proceed, which is recorded.
• Restrict access or encrypt the content.
• Show a policy tip — an in-context message in Outlook, Office, or Teams warning the user before they do something risky and explaining why.
• Notify admins via incident reports and surface matches in Activity explorer and DLP alerts.

Policy tips are an exam favorite because they educate users at the moment of risk rather than silently blocking — they reduce accidental leaks while keeping people informed.

Choosing DLP vs the neighbors

DLP sits next to sensitivity labels, and the two cooperate (a DLP rule can act on labeled content), but they answer different verbs:

• "Classify / mark / encrypt this file so protection follows it" → sensitivity label.
• "Stop users from sharing or copying this sensitive data" → DLP.
• "Keep or delete this content on a schedule" → retention.
• "Find and review content for a legal case" → eDiscovery.

Trap: the word "prevent" can lure candidates toward a security product. Microsoft Defender protects endpoints, identities, and workloads against threats; Azure Firewall / NSGs filter network traffic. Preventing sensitive data from being shared inappropriately is squarely a Microsoft Purview DLP task. Likewise, DLP is not visibility-only — if a scenario merely wants to see where sensitive data is, that is Content explorer / classification, not DLP.

How a DLP Policy Is Built and Monitored

A DLP policy is assembled from a few parts that SC-900 may reference by name. Understanding the structure helps you recognize DLP in a scenario:

• Locations — the workloads the policy applies to (Exchange, SharePoint, OneDrive, Teams, Devices, Office apps, Defender for Cloud Apps, on-premises).
• Rules — each rule contains conditions, actions, and user notifications. A policy can hold several rules with different sensitivity thresholds.
• Conditions — what to look for, reusing classification: a sensitive information type, a trainable classifier, a sensitivity label, or a count threshold (for example "10 or more credit card numbers").
• Actions — what to do: block, restrict, encrypt, or audit.
• User notifications and policy tips — what the user sees and whether they can override.
• Incident reports / alerts — who gets notified when the rule matches.

A common design pattern is graduated enforcement: a low-count rule that only audits and shows a policy tip, and a high-count rule that blocks with override when a lot of sensitive data is present. This balances productivity against protection — most accidental exposures are caught by the tip, while serious leaks are blocked.

Once live, DLP results are monitored in the DLP alerts dashboard and surfaced in Activity explorer, tying this section back to the visibility tools earlier in the chapter. So the full loop is: classify the data, label it, write a DLP policy that acts on the classification or label, then monitor matches in Activity explorer and DLP alerts. For SC-900 you do not configure these in detail — you recognize that DLP is the prevention control, that one policy spans many locations, and that it consumes the same classification signals as labels and retention.