In this module
AD4.7 Building Your First DLP Policies
Figure AD4.7 — DLP deployment in three phases. Simulation mode (2 weeks) shows what would be blocked without affecting users. Policy tips (1 week) warn users and allow overrides. Enforcement (ongoing) blocks sensitive content from leaving the organization, with user override available for legitimate business needs.
Building DLP Policy 1: Personal Data Protection
Navigate to purview.microsoft.com → Solutions → Data Loss Prevention → Policies → Create policy.
Step 1 — Template selection. Select "Custom policy" (templates are useful starting points but custom gives you full control). Name: "DLP — Personal Data Protection."
Step 2 — Locations. Enable these locations (E3 scope): Exchange email, SharePoint sites, OneDrive accounts. Leave Teams chat and Endpoint devices disabled (these require E5).
Step 3 — Policy rules. Create a rule:
Rule name: "Block external sharing of personal data"
Conditions — Content contains sensitive information types: Add these UK/EU-relevant types:
- UK National Insurance Number (NINO) — minimum count: 1
- Credit Card Number — minimum count: 1
- UK Passport Number — minimum count: 1
- EU Debit Card Number — minimum count: 1
- IBAN — minimum count: 3 (single IBANs appear in legitimate invoices — 3+ indicates a list)
Conditions — Content is shared with: People outside your organization.
This rule only triggers when sensitive data is being shared EXTERNALLY. Internal sharing of personal data isn't blocked — it's normal for HR to share employee NINOs with payroll. The risk is external sharing, and that's what DLP catches.
Actions:
- Restrict access or encrypt the content in Microsoft 365 locations: Block only people outside your organization (internal users can still access, external sharing is blocked)
- Send incident reports: Send to your admin email when a match occurs
User notifications: Enable. Show policy tips to users in Outlook and SharePoint when a match is detected.
User overrides: Enable. Allow users to override the block with a business justification. This is important — there are legitimate reasons to share personal data externally (sending employee tax forms to HMRC, sharing contract details with a client's solicitor). The override creates an audit trail of WHO overrode, WHEN, and WHY, which is far better than silently blocking all external sharing and forcing users to find workarounds.
Step 4 — Policy mode: Select "Run the policy in simulation mode" (also called test mode). This logs all matches without blocking anything — giving you 2 weeks of data to review before enforcement.
Click "Submit" to create the policy.
Building DLP Policy 2: Financial Data Protection
Create a second policy following the same process.
Name: "DLP — Financial Data Protection"
Locations: Exchange email, SharePoint sites, OneDrive accounts.
Rule: "Block external sharing of financial data"
Conditions — Content contains sensitive information types:
- Credit Card Number — minimum count: 5 (a single credit card number may be in a normal email; 5+ indicates a bulk list)
- UK Bank Account Number — minimum count: 3
- SWIFT Code — minimum count: 3
Conditions — Content is shared with: People outside your organization.
Actions: Block external users, send incident report to admin.
User notifications and overrides: Same as Policy 1 — tips enabled, override with justification enabled.
Mode: Simulation mode.
Understanding Sensitive Information Types
DLP policies detect data using Sensitive Information Types (SITs) — pattern-matching rules that identify specific data formats. A UK NINO matches the pattern "two letters, six digits, one letter" (e.g., AB123456C). A credit card number matches Luhn-algorithm-valid 13-19 digit sequences.
Microsoft provides 300+ built-in SITs covering personal data, financial data, health records, and government IDs for dozens of countries. For UK organizations, the most relevant are: UK National Insurance Number, UK Electoral Roll Number, UK NHS Number, UK Passport Number, Credit Card Number, IBAN, and UK Bank Account Number.
You can also create custom SITs for organization-specific data. If NE has a client reference number format (e.g., NE-2026-XXXXX), you can create a custom SIT that matches this pattern and include it in DLP policies. Navigate to purview.microsoft.com → Data Classification → Sensitive info types → Create.
Reviewing simulation results
After 2 weeks in simulation mode, review what the policies detected. Navigate to purview.microsoft.com → Data Loss Prevention → Activity explorer.
The Activity Explorer shows every DLP match: the document or email, the sensitive information type detected, the user, the location, and whether the content was shared internally or externally. Filter by your two policies to see the matches for each.
What you're looking for: true positives (genuine sensitive data shared externally — this is what you want to catch) and false positives (legitimate content that triggered a match but isn't actually sensitive — e.g., a 16-digit order number that looks like a credit card number to the SIT pattern matcher).
For false positives, you have two options: increase the minimum count threshold (requiring 5+ matches instead of 1), or add a condition that requires the SIT to have high confidence (each SIT has a confidence level — "high" means the pattern match is very likely to be correct; "medium" means it might be a false positive).
After reviewing the simulation results and adjusting for false positives, you're ready to move to enforcement — covered in AD4.8.
# Check DLP policy status
Connect-IPPSSession
Get-DlpCompliancePolicy | Select-Object Name, Mode, ExchangeLocation,
SharePointLocation, OneDriveLocation | Format-List
# Check policy rules
Get-DlpComplianceRule | Select-Object Name, ParentPolicyName,
ContentContainsSensitiveInformation, BlockAccess | Format-ListAfter 2 weeks in simulation mode, your DLP Activity Explorer shows 47 matches for the Personal Data Protection policy. 38 are genuine (emails containing NINOs sent to external accountants — legitimate but should be encrypted). 9 are false positives (16-digit equipment serial numbers flagged as credit card numbers). How do you handle this before enforcement?
Option A: Leave the policy as-is — 9 false positives out of 47 is an acceptable rate.
Option B: Increase the credit card minimum count from 1 to 3 (reducing false positives from serial numbers), add a "high confidence" condition for credit card detection, and keep the NINO threshold at 1 (since every NINO match was genuine). Then switch to "test with policy tips" for 1 week before full enforcement.
The correct answer is Option B. A 19% false positive rate (9/47) will generate user frustration once the policy is enforced — users will see policy tips on legitimate emails about equipment serial numbers. Adjusting the credit card threshold and confidence level reduces false positives without weakening the detection for genuine sensitive data. The "test with policy tips" phase gives you a week to verify the tuning before enforcement.
Connect-IPPSSession
Get-DlpCompliancePolicy | Select-Object Name, Mode, Enabled | Format-TableTry it: Build your first DLP policy
Navigate to purview.microsoft.com → Data Loss Prevention → Policies → Create policy.
Build the Personal Data Protection policy from this subsection: custom template, Exchange + SharePoint + OneDrive locations, UK NINO + Credit Card detection, external sharing only, block + notify + override, simulation mode.
After creating the policy, wait 24 hours for it to begin scanning. Then send yourself a test email to your personal address containing a fictional NINO (e.g., AB123456C). Check the Activity Explorer after 24-48 hours — the email should appear as a DLP match.
Run the PowerShell verification to confirm both policies are active:
If the policy shows Mode: TestWithoutNotifications and Enabled: True, it's running in simulation mode and scanning content.
Creating a custom Sensitive Information Type
Microsoft's built-in SITs cover standard data formats (NINOs, credit cards, passports). But your organization likely has data formats that are unique to your business: client reference numbers, project codes, employee IDs, or internal account numbers. If these formats contain sensitive information, create a custom SIT to detect them.
Navigate to purview.microsoft.com → Data Classification → Sensitive info types → Create sensitive info type.
Example: NE Client Reference Number
NE uses a client reference format: NE-2026-XXXXX (NE dash year dash 5 digits). This appears in contracts, invoices, and correspondence. A document containing multiple client references may be a client list — which is Confidential.
Name: "NE Client Reference Number" Description: "Northgate Engineering client reference format NE-YYYY-NNNNN" Pattern: Add a regular expression: NE-\d{4}-\d{5} Confidence level: Medium (the pattern could theoretically appear in other contexts) Supporting evidence: Add a keyword list with terms that commonly appear near client references: "client," "contract," "proposal," "invoice," "engagement"
Click "Create." The custom SIT is now available in DLP policy rules alongside Microsoft's built-in types.
Add the custom SIT to your DLP policies for internal-specific data protection. The built-in SITs catch universal data types (credit cards work the same everywhere). Custom SITs catch YOUR organization's specific sensitive data.
Testing DLP policies with realistic data
After creating policies, test them with realistic (but fictional) data to verify they trigger correctly. Don't use real NINOs or credit card numbers in testing — create fictional test data that matches the pattern.
Test data for UK National Insurance Number: AB123456C (valid format, not a real NINO)
Test data for credit card number: 4111 1111 1111 1111 (Visa test card number — passes Luhn validation, universally recognized as a test number, not associated with any real account)
Test procedure:
1. Create a Word document containing your test data (3-5 instances of the test NINO and test credit card number) 2. Save the document to OneDrive 3. Try to share it externally via a sharing link — DLP should detect and log/block the match 4. Compose an Outlook email to a personal address with the test document attached — DLP should detect and show a policy tip 5. Check Activity Explorer after 24 hours — both test events should appear as DLP matches
If the tests don't trigger DLP matches, check: is the policy assigned to your location (Exchange, SharePoint, OneDrive)? Has the policy had time to propagate (up to 24 hours for new policies)? Is the content count threshold met (if you set a minimum of 3 credit cards, you need 3 in the test document)?
Before moving DLP policies from simulation to enforcement, run a structured test: create a test email containing a fictional National Insurance Number (format: AB 12 34 56 C) and send it to an external personal email address. With the policy in simulation mode, the email sends but generates an Activity Explorer entry. After enforcement, the email should be blocked with a policy tip displayed to the sender. This test confirms the sensitive information type detection works, the policy action triggers correctly, and the user notification displays. Repeat the test after any policy modification to verify the change works as expected.
You're reading the free modules of M365 Security: From Admin to Defender
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.