A DLP alert fires in Microsoft Purview indicating that a Finance department user shared a SharePoint document containing Social Security Numbers with an external email address. Before taking action, the security admin needs to review the matched content, understand which DLP policy was triggered, and determine whether the sharing was potentially authorized. What is the correct first action?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Investigate before you incinerate. DLP alerts contain a gold mine of context: the matched sensitive content snippet, exactly which rule fired, the user who triggered it, the recipient, the file name, and the confidence level. A Finance analyst might have legitimately shared SSN data with an external auditor, and disabling their account first (option A) turns a false positive into a workplace incident. Read the alert, understand the context, then decide.
Full explanation below image
Full Explanation
Microsoft Purview DLP alerts appear in the Microsoft Purview compliance portal under Data loss prevention > Alerts. Each alert contains: the policy name and specific rule that triggered, the user who took the action, the specific content that matched (with the sensitive information type and confidence level), the recipient or sharing destination, and a timeline of events. This investigation workflow is essential because DLP alerts can be true positives (actual policy violations), false positives (benign actions that match the policy pattern), or authorized exceptions (sharing that is permitted but tracked). Disabling a user's account based on an unreviewed alert could be an inappropriate response to an authorized workflow (e.g., a Finance team member sharing a report with an external auditor).
Option A (immediately disabling the user account) violates the principle of investigating before acting. A Finance department employee sharing SSN data with an external party could be entirely authorized — payroll processing, external auditors, authorized third-party services. Disabling the account without investigation causes operational disruption and, if the sharing was authorized, constitutes an unjustified action against an employee. DLP alert investigation should always precede disruptive remediation.
Option C (tenant-wide Content Search for all SSN files) is a disproportionate initial response to a single DLP alert. While a broader audit may eventually be warranted as a follow-up, the immediate action should be to understand the specific alert that fired — what happened, who did it, and whether it was a violation. A tenant-wide content search is time-consuming and does not address the specific incident at hand.
Option D (creating a new DLP policy blocking all external SharePoint sharing) is both reactive and disproportionate. Blocking ALL external SharePoint sharing across the entire organization would destroy legitimate collaboration capabilities (partner file sharing, client deliverables, vendor access). A policy change of this magnitude requires analysis, stakeholder approval, and careful scoping — not an immediate response to a single alert.
Exam tip: The DLP alert investigation workflow in Microsoft Purview follows a pattern similar to security incident response: (1) Triage — review the alert details and context; (2) Classify — true positive, false positive, or authorized exception; (3) Respond — appropriate action based on classification; (4) Tune — adjust the DLP policy if needed to reduce false positives or improve coverage. Know that DLP alerts in Purview can be reviewed alongside Activity Explorer, which provides a unified audit trail of data sensitivity events across Microsoft 365.