17.3 Reviewing & Responding to DLP Alerts, Events & Reports

Configuring a DLP policy is only the first half of the job. Once policies are live, the Microsoft 365 administrator's ongoing responsibility is to review and respond to DLP alerts, events, and reports — this is the third blueprint bullet under Domain 4. The Purview compliance portal provides three primary surfaces for this work: the DLP Alerts queue, the DLP Reports dashboards, and Activity explorer.

---

DLP Alerts

Open Data loss prevention → Alerts in the Purview compliance portal to see the alert queue. Each alert represents one or more policy matches that Purview has correlated into a single incident-worthy event. The alert tile shows:

• Severity — High, Medium, or Low, derived from the rule configuration
• Policy — the DLP policy that generated the alert
• Matched item — the file, email, message, or Copilot prompt/response
• Detected SITs and sensitivity labels — exactly which sensitive information types and labels were found
• User — the account that performed the activity
• Activity — what the user did (shared, copied to USB, uploaded to unallowed browser, etc.)
• Rule — the specific rule inside the policy that triggered
• Status — New, In progress, or Resolved

Selecting an alert opens the alert details flyout, which lets you see the full metadata, the policy configuration that fired, and a link to the matched item in Content explorer (subject to Content explorer permissions — a separate role assignment that not all DLP administrators have).

---

The Triage Workflow

Microsoft's recommended triage workflow for each DLP alert is:

1. Review the alert — read the alert metadata to understand what was matched, by whom, and where
2. Investigate the matched item — open the item in Content explorer to confirm the sensitive content is actually present and to see the surrounding context (the rest of the email, the file contents)
3. Classify — decide whether the alert is a false positive (the SIT matched but the content is not actually sensitive, or the activity is legitimate business) or a real violation (sensitive content was shared inappropriately)
4. Take action:
   • Dismiss as false positive — closes the alert and feeds back into policy tuning
   • Resolve — confirms a real violation was addressed (e.g., the user removed the content, access was revoked)
   • Escalate for user education — send the user a notification or training link
   • Tune the policy — adjust conditions, scope, or mode to reduce future matches of this kind
5. Update the alert status — mark as Resolved with a note for audit history

False Positives vs Real Violations

A false positive typically falls into one of three buckets:

• SIT over-matching — a number that looks like a Social Security number but is actually an internal employee ID
• Legitimate business workflow — HR sharing a list of new hires with payroll, which is approved even though SSNs are present
• Test or sample data — a document containing clearly fake credit card numbers used for training

A real violation is an actual exposure of sensitive content to an unauthorized recipient or channel — for example, a salesperson emailing a customer list with credit card numbers to a personal Gmail account.

---

DLP Reports and Dashboards

Open Reports → Data loss prevention to see the reporting dashboards. The DLP reports are read-only views that aggregate policy matches over a selectable time range and surface trends. Key widgets include:

• DLP policy matches over time — line chart showing daily match volume per policy; a sudden spike often indicates a new sharing pattern or a misconfigured rule
• Top sensitive information types matched — bar chart of which SITs are firing most frequently, useful for tuning SIT confidence or instance counts
• Top users with policy matches — identifies users who repeatedly trigger policies and may need targeted training
• False positive rate — the percentage of resolved alerts that were dismissed as false positives; a high false positive rate is the clearest signal that a policy needs tuning
• Policy effectiveness — compares matches to enforcement actions (blocks, overrides, audits) and shows whether the policy is doing what was intended

Reports can be filtered by policy, workload, SIT, user, and time range. Export options let compliance officers share snapshots with auditors or include them in periodic compliance reviews.

---

Activity Explorer for DLP Events

Activity explorer (under Data loss prevention → Activity explorer) is the event-level view — every individual DLP match, including ones that did not escalate to an alert, appears here. Where the alerts queue correlates events into incidents, Activity explorer shows the raw stream. Use it to:

• Investigate a specific user's behavior over time
• Filter by activity type (copy to USB, upload to unallowed browser, Teams message blocked)
• See endpoint and cloud events in one unified view
• Spot patterns that have not yet met alert thresholds but are trending toward a problem

Activity explorer is also where most tuning decisions get validated: after you adjust a policy, you watch Activity explorer to confirm match volume moves in the expected direction.

---

Tuning a DLP Policy

Tuning is the act of changing a policy to reduce false positives, catch missed violations, or progress toward enforcement. The most common tuning levers are:

• Conditions — add or remove SITs, change Match any/Match all logic, adjust the minimum instance count
• Scope — narrow include/exclude lists to focus the policy on the users, groups, or sites where it matters
• SIT confidence level — raise from Medium to High to reduce over-matching (fewer false positives, possibly more false negatives)
• Policy mode — move from test-with-tips to enforce once match volume and false positive rate are acceptable
• Actions — switch from audit-only to block, or add a user override with business justification

The canonical lifecycle is: start in test with policy tips, review alerts and Activity explorer for two to four weeks, tune conditions and scope, then switch to enforce. Revisit reports monthly to catch drift as new content types and sharing patterns emerge in the tenant.

---

Integration with Microsoft Defender for Cloud Apps

Purview DLP covers Microsoft 365 workloads and Endpoint DLP covers devices. For third-party cloud apps — Box, Dropbox, Google Workspace, Salesforce, and other sanctioned SaaS — DLP enforcement is extended through Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security).

Defender for Cloud Apps connects to sanctioned SaaS apps via API connectors and uses session controls for real-time enforcement. A Purview DLP policy can be scoped to the Microsoft Defender for Cloud Apps location to apply the same SIT-based conditions to uploads, downloads, and sharing in connected third-party apps. The flow is:

1. Connect the third-party app in Defender for Cloud Apps (e.g., authorize the Box API connector)
2. Create or edit a Purview DLP policy and select the Defender for Cloud Apps location
3. Define the same SIT/label conditions as for M365 workloads
4. Choose an action — alert, block, or require session control through Conditional Access App Control

This gives the administrator a single DLP policy framework spanning Microsoft 365, endpoints, and sanctioned third-party cloud apps, with all events flowing into Activity explorer for unified investigation.

---

Key Takeaways

• The DLP alert queue (Data loss prevention → Alerts) correlates policy matches into triageable incidents, each surfacing the matched item, SITs, user, activity, and triggering rule
• The triage workflow is review → investigate in Content explorer → classify → dismiss / resolve / escalate → tune the policy
• DLP reports under Reports → Data loss prevention show policy matches over time, top SITs, top users, false positive rate, and policy effectiveness
• Tuning levers include conditions, scope, SIT confidence, policy mode, and actions; the recommended lifecycle is test-with-tips → tune → enforce
• Defender for Cloud Apps extends Purview DLP to sanctioned third-party cloud apps such as Box, Dropbox, Google Workspace, and Salesforce via API connectors and session controls