What Microsoft Purview DLP Actually Does

Data Loss Prevention in Microsoft Purview monitors content flowing through Exchange Online, SharePoint, OneDrive, Microsoft Teams, and — with the Endpoint DLP extension — Windows 10/11 devices. When content matches a configured policy (for example, a message containing a German IBAN number addressed to an external recipient), Purview can block delivery, display a policy tip to the sender, notify compliance officers, or log the event for audit review.

The critical distinction from perimeter firewalls is that DLP operates on content, not network paths. An employee copying a customer database to a USB stick while connected to your office LAN bypasses every network security control. Endpoint DLP catches that action at the operating system level and can block it, log it, or require business justification before allowing it.

DLP Policy Architecture: Three Layers

Step 1: Start with Simulation Mode — Never Block First

The single most common DLP deployment failure is starting in enforce mode. A policy that blocks email containing a pattern it misidentifies as sensitive will stop legitimate business communication, generate angry user escalations, and result in the policy being turned off entirely. Always deploy in “Test it out first” mode (also called Simulation mode in Purview) for at least two weeks before enforcing.

In Simulation mode, Purview records every match the policy would have triggered but takes no action against the user. Review the activity explorer in Purview after one week. Look for false positives — legitimate business content flagged incorrectly — and adjust your policy conditions before switching to enforce mode. Refine, then enforce.

Step 2: Choose Sensitive Information Types for Berlin SMBs

Microsoft Purview ships with over 200 built-in Sensitive Information Types (SITs). For a Berlin SMB handling customer and employee data, the most relevant are:

Step 3: Define Policy Actions by Risk Level

Not every DLP match warrants blocking. Structure your policies around three action tiers:

• Low risk — Policy tip only: Show the user a notification that the content appears to contain sensitive data. Let them proceed if they confirm it is intentional. Logged for audit. Use for internal sharing of moderately sensitive content.
• Medium risk — Override with justification: Block the action but allow the user to override by entering a business reason. The justification is logged and can trigger a compliance alert. Use for external sharing of sensitive data categories.
• High risk — Block with no override: Hard block with no user override path. Compliance officer is notified. Use for credit card numbers, national ID numbers, and credentials leaving the tenant entirely.

Step 4: Integrate DLP with Sensitivity Labels

Sensitivity Labels in Microsoft Purview (formerly Azure Information Protection) allow users to manually classify documents and emails as Public, Internal, Confidential, or Highly Confidential. DLP policies can then enforce actions based on label assignment rather than content scanning alone — which is faster, more accurate, and catches content that pattern-matching would miss (for example, a spreadsheet with customer data where column headers vary).

For a Berlin SMB, a practical starting label schema is: Public (marketing materials, public pricing), Internal (general business communication), Confidential (customer data, contracts, financial records), Highly Confidential (HR records, legal documents, intellectual property). Apply DLP rules that block external sharing of Confidential and Highly Confidential labeled content unless explicitly approved.

Step 5: Review DLP Activity Explorer and Alerts

Navigate to Microsoft Purview > Data loss prevention > Activity explorer to see every DLP event across your tenant — matches, policy tips shown, blocks, and user overrides with their stated justifications. Filter by user, policy, or sensitive information type. Weekly review of the activity explorer catches both data risk patterns (the same user repeatedly overriding a block) and policy calibration issues (a policy generating hundreds of false positives on a particular template).

Configure alert policies under DLP > Alerts so that high-severity matches (credit card data, national IDs) generate immediate email or Teams notifications to your compliance officer or IT administrator. Do not rely on weekly manual review for high-risk data categories — the 72-hour GDPR breach notification window does not accommodate that cadence.

DLP Deployment Checklist for Berlin SMBs

How IT Experts Berlin Implements Purview DLP

We deploy Purview DLP for Berlin SMBs as a phased four-week engagement: audit logging verification and Sensitive Information Type selection in week one; simulation-mode GDPR baseline policy deployment in week two; false-positive review and policy refinement in week three; enforce-mode cutover and alert configuration in week four. Clients receive a DLP policy documentation pack suitable for their GDPR Article 30 records. Contact us for a free Purview readiness assessment.