In this module

AD4.8 DLP Policy Tips and User Education

5-6 hours · Module 4 · Free

Operational Objective

DLP policies that silently block email or sharing without explaining why create frustrated users who find workarounds — copying data to personal USB drives, taking screenshots, or emailing content to personal addresses via their phone. Policy tips transform DLP from a blocking tool into an education tool: the user sees a clear message explaining what was detected, why it's blocked, and what they can do instead (encrypt the email, remove the sensitive data, or override with a business justification). This approach changes user behavior over time — after seeing policy tips repeatedly, users start thinking about data sensitivity before they hit "Send." This subsection configures policy tips, customizes the messages users see, moves policies from simulation to "test with notifications" mode, and builds the user communication that accompanies the DLP enforcement rollout.

Deliverable: DLP policies transitioned from simulation to "test with notifications" mode, custom policy tip messages configured for each policy, and a user communication prepared for the enforcement announcement.

Estimated completion: 20 minutes

Figure AD4.8 — DLP policy tips appear in context: in Outlook before sending and in SharePoint/OneDrive when sharing. The message explains what was detected and offers an override with justification. This educates users at the moment they need it most — when they're about to share sensitive data externally.

Transitioning to "test with notifications"

After reviewing 2 weeks of simulation data (AD4.7) and adjusting for false positives, transition the policies to show policy tips without enforcing blocks. Navigate to purview.microsoft.com → Data Loss Prevention → Policies → select your policy → Edit → Policy mode → select "Run the policy in simulation mode and show policy tips while in simulation mode" (also described as "Test with policy tips" in some portal versions).

This mode shows the yellow policy tip bar to users when they trigger a DLP match, but doesn't actually block the send or share. The user sees: "This message contains sensitive information (UK National Insurance Number). Review before sending." They can send anyway — the goal at this stage is awareness, not enforcement.

Run in this mode for 1 week. Monitor: how many users see policy tips, how many send despite the tip, and how many modify their email (remove the sensitive data or add encryption) after seeing the tip. This data tells you whether policy tips are effective at changing behavior before you add blocking.

Customising policy tip messages

Default policy tip messages are generic. Custom messages that reference your organization's data protection policy are more effective.

In the DLP policy rule settings, under "User notifications" → "Customize the policy tip text":

For the Personal Data Protection policy: "This email/file contains personal data (e.g., National Insurance Numbers or credit card numbers) that is restricted from external sharing under NE's Data Protection Policy. If you need to share this data externally for a legitimate business purpose, click 'Override' and provide a justification. For guidance, contact security@northgateeng.com."

For the Financial Data Protection policy: "This email/file contains financial data (e.g., bank account numbers or bulk credit card data) that is restricted from external sharing. If this is a legitimate business need (e.g., sending to your bank or accountant), click 'Override' and provide a justification."

The custom message should: state what was detected, reference the organizational policy (this makes it a business rule, not an arbitrary IT block), provide the override option, and give a contact for questions. Keep it under 100 words — users don't read long policy tips.

Moving to enforcement

After 1 week of "test with notifications" with no significant issues (users understand the tips, false positive rate is acceptable, no critical business processes are disrupted), move to full enforcement.

Navigate to the DLP policy → Edit → Policy mode → "Turn it on right away."

Now the policy actively blocks external sharing of sensitive data. Users who trigger the policy see the policy tip AND the email/share is blocked. They can override with a justification (which is logged and reviewable). They cannot bypass the policy without providing a reason.

Communicate the enforcement to all users: "Starting [date], our data protection policies will prevent sensitive information — such as National Insurance Numbers, credit card numbers, and bank details — from being shared externally via email or SharePoint. If you see a policy tip warning, review your content before sending. If you need to share sensitive data externally for a legitimate reason, you can override with a business justification. This protects our organization and our clients from accidental data exposure."

What to do when DLP blocks a legitimate business action

Users who encounter DLP blocks for the first time will call the helpdesk. Your helpdesk team needs a script — just like the compliance remediation script in AD3.7.

Scenario: User tries to email a document to a client and DLP blocks it.

Step 1 — Identify the block. Ask the user what they were trying to send and to whom. Check the DLP Activity Explorer for the match: purview.microsoft.com → DLP → Activity explorer → search by user. The match detail shows which sensitive information type triggered the block.

Step 2 — Assess legitimacy. Is the external sharing legitimate? Sending a client contract to the client's solicitor: legitimate. Sending a spreadsheet of employee NINOs to a personal email address: not legitimate. This assessment takes 30 seconds — the business context is usually obvious.

Step 3 — Guide the user. For legitimate sharing: instruct the user to override with a business justification. "Click the policy tip, select 'Override,' and enter a brief reason — for example, 'Sending contract to client's legal team per project agreement.'" For illegitimate sharing: explain why the data can't be shared externally and suggest an alternative (e.g., share through a secure portal, remove the sensitive data from the document, or encrypt the document with the "Highly Confidential" label and add the specific recipient).

Step 4 — Document. If the same legitimate workflow generates DLP blocks regularly, create a policy exception (AD4.7's decision point) to eliminate the recurring block.

Beyond the initial enforcement email, create a one-page reference for common DLP scenarios. Post it on the intranet and link to it from the policy tip "Learn more" URL.

"Data Protection: What You Need to Know"

"Our DLP system automatically detects sensitive information in emails and documents you share. Here's what to expect:

If you see a yellow bar in Outlook: Your email contains data our system has identified as sensitive (such as National Insurance Numbers or financial account details). Review the recipients — if you're sharing externally and the data is genuinely needed by the external party, click Override and provide a brief business reason. If you realize the data shouldn't be shared externally, remove it from the email.

If sharing is blocked in SharePoint: The file you're trying to share externally contains sensitive data. If the external person genuinely needs this file, use the Override option. If they don't need the sensitive data, create a copy without the sensitive content and share that instead.

If you're not sure: Contact security@northgateeng.com. We'd rather help you share data safely than have you find a workaround that bypasses protection."

The tone matters: the one-pager should feel helpful, not punitive. DLP is protecting the user from accidental mistakes, not monitoring their behavior. Frame it as "we're helping you avoid a data breach" not "we're watching what you send."

Configuring the "Learn more" link in policy tips

In the DLP policy rule, under User notifications, you can specify a compliance URL — a link that appears in the policy tip as "Learn more." Set this to the intranet page where your data protection one-pager lives.

Navigate to your DLP policy → Edit rule → User notifications → Compliance URL → enter the URL.

When a user sees a policy tip in Outlook or SharePoint, the "Learn more" link takes them directly to your guidance page. This closes the education loop: the policy tip warns them, the "Learn more" link explains what to do, and the override option lets them proceed with documentation.

Monitoring overrides

After enforcement, track DLP overrides — these are the cases where users chose to share sensitive data externally despite the policy tip. Navigate to purview.microsoft.com → Data Loss Prevention → Activity explorer → filter by "Override."

Each override shows: the user, the justification they provided, the sensitive data detected, and the recipient. Review overrides weekly for the first month. Legitimate overrides (sending tax forms to HMRC, sharing bank details with the company's accountant) are expected. Suspicious overrides (bulk data sent to a personal email address with a vague justification) warrant investigation.

If a specific user consistently overrides DLP policies with weak justifications, have a conversation. The override feature trusts users to make good decisions — but that trust needs monitoring to prevent abuse.

# Check DLP policy matches and overrides
Connect-IPPSSession
Get-DlpDetailReport -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) |
    Where-Object { $_.PolicyAction -eq "Override" } |
    Select-Object Date, User, PolicyName, SensitiveInformationType,
        OverrideJustification |
    Format-Table -AutoSize

Compliance Myth: "Users should never be able to override DLP — if it's blocked, it should stay blocked"

Rigid blocking without override creates two problems: users find workarounds (screenshot, retype, use a personal device) that are completely invisible to DLP, and legitimate business processes are disrupted (sending employee data to HMRC, sharing contracts with external solicitors). An override with justification is a recorded decision that's auditable and reviewable — far better than an invisible workaround with no audit trail. The override log is a compliance asset: it demonstrates that your organization has a process for handling exceptions, that each exception is documented, and that the exceptions are reviewed. Regulators and auditors view this as mature data protection, not weak enforcement.

Decision point

Your DLP policy has been in enforcement mode for 2 weeks. The override log shows that the same user in the finance team overrides the policy 3-4 times per week to send bank details to external vendors. Each override has a justification of "Routine vendor payment." Is this a problem?

Option A: No — the overrides are justified and routine. The finance team legitimately sends bank details to vendors for payment processing.

Option B: Yes — the frequency suggests the DLP policy is too broad for this workflow. Create a DLP exception that allows the finance team's shared mailbox to send financial SITs to a pre-approved list of vendor domains without triggering the block. Keep the policy active for all other external sharing from the finance team.

The correct answer is Option B. Frequent overrides for the same routine activity indicate a policy that's blocking legitimate work. The solution isn't to remove the override or accept the noise — it's to refine the policy. Add a condition to the DLP rule that excludes emails from the finance shared mailbox to pre-approved vendor domains. This eliminates the routine overrides while keeping the policy active for unexpected external sharing. Document the exception with the vendor domain list and review it quarterly.

Try it: Customise policy tips and transition to notifications

Navigate to purview.microsoft.com → Data Loss Prevention → Policies → select your Personal Data Protection policy → Edit.

Under the policy rule, expand "User notifications" and customize the policy tip text with an organization-specific message (use the template in this subsection, adapted for your organization's name and contact details).

Change the policy mode from simulation to "test with notifications." Save.

Send yourself a test email to a personal address containing a fictional NINO (AB123456C). In Outlook, you should see the yellow policy tip bar before sending. The email should still send (test mode doesn't block), but the tip should appear.

Check the Activity Explorer after 24 hours to see the match logged with the "Notify" action.

A user in HR needs to email employee National Insurance Numbers to HMRC for annual tax reporting. The DLP policy detects the NINOs and shows a policy tip blocking the send. The user clicks "Override" and enters the justification "Annual HMRC PAYE submission." What happens?

The email is still blocked — HMRC submissions should use a dedicated portal, not email — This is a valid security recommendation but the DLP policy is configured to allow overrides. The email sends with the override.

The email is sent and the DLP log shows no record of the override — No. Overrides are always logged with the user, timestamp, justification, and content details.

The email is sent successfully, and the DLP Activity Explorer logs the override with the user's name, the justification "Annual HMRC PAYE submission," the NINOs detected, and the recipient (HMRC) — creating a full audit trail of the decision to share personal data externally — Correct. The override works as designed: the user provides a reason, the email sends, and everything is logged. During the weekly override review, the admin sees this entry and confirms it's a legitimate business need. The audit trail satisfies GDPR's requirement to document data sharing decisions — each override is a recorded, justified decision to process and share personal data.

The user needs admin approval before the override takes effect — Standard DLP overrides don't require admin approval. The user overrides immediately. If your organization needs approval-based overrides, you'd need a SOAR workflow — which is beyond E3 scope.

Policy tip text supports basic HTML formatting — bold and line breaks — but not links or images. Keep the text under 250 characters for Outlook and under 500 characters for SharePoint. Longer text gets truncated and users see an ellipsis. Test the tip text in each application (Outlook, Word, SharePoint) after deployment because the rendering differs slightly between applications.

Operational Artifact — DLP Enforcement Rollout Plan

Rollout sequence: Simulation mode (2 weeks — review Activity Explorer for false positives), Test with notifications (1 week — users see tips, send anyway), Full enforcement (ongoing — blocks with override). Custom policy tip messages reference NE's Data Protection Policy. Override monitoring: weekly review of Activity Explorer for override justifications. User communication sent before enforcement day. Exception process for routine workflows (finance vendor payments, HMRC submissions) that generate frequent overrides.

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.

View Pricing See Full Syllabus

← Previous Next →