Microsoft Purview Data Loss Prevention Design and Workload Protecof This Lesson

Microsoft Purview Data Loss Prevention, commonly called DLP, helps organizations identify sensitive information, monitor how it is used, and prevent it from being shared through unauthorized channels.

For a Microsoft Security Operations Analyst, DLP is relevant because suspected data loss may represent:

• An accidental policy violation
• An improperly configured business process
• An employee attempting to bypass security controls
• A compromised account
• A malicious insider
• Active data exfiltration

The analyst must understand where DLP policies are configured, which workloads they protect, how policy matches become alerts, and how to investigate the affected users, devices, messages, and files.

A central exam distinction is that Microsoft Purview is where DLP policies and data-protection controls are managed, while Microsoft Defender XDR can provide the unified incident queue used to correlate and investigate DLP alerts alongside endpoint, identity, email, and cloud-app signals. Key Concepts

What Is Data Loss Prevention?

DLP stands for Data Loss Prevention.

Its purpose is to identify sensitive information and control actions that could expose that information to unauthorized people or locations.

Examples of sensitive information include:

• Credit card numbers
• Social Security numbers
• National identification numbers
• Health and medical information
• Employee records
• Financial forecasts
• Legal documents
• Source code
• Engineering drawings
• Contracts
• Intellectual property
• Custom business identifiers

Microsoft Purview DLP can monitor data across Microsoft 365 services and supported endpoints. Depending on the configured policy, it can audit activity, warn users, block actions, permit justified overrides, and generate alerts for investigation.

Microsoft describes DLP as protecting sensitive data while it is:

• At rest: Stored in a location such as SharePoint or OneDrive
• In use: Being opened, printed, copied, or otherwise handled
• In motion: Being emailed, uploaded, shared, or transferred

DLP policies can monitor user activity and take protective actions when their configured conditions are met. DLP Is a Control System, Not an Absolute Guarantee

DLP makes data exfiltration more difficult and prevents many accidental disclosures, but it cannot guarantee that a determined person will never remove information from an organization.

For example, a technical policy might prevent a user from:

• Copying a protected file to a USB drive
• Uploading it to personal cloud storage
• Emailing it to an external recipient
• Printing it
• Copying its contents into an unauthorized application

However, technical DLP controls cannot necessarily prevent someone from photographing a screen with an unmanaged external device.

Therefore, DLP must be combined with:

• Physical security
• Access control
• Least privilege
• User education
• Insider risk monitoring
• Security awareness
• Audit logging
• Incident response procedures
• Management and human-resources processes

DLP should be treated as part of a layered data-protection strategy rather than as a complete solution by itself.

---

Core Components of a DLP Policy

A DLP policy generally answers five questions.

1. Where Should the Policy Apply?

The policy location determines which workloads or services are monitored.

The core locations covered in this lesson are:

• Exchange Online
• SharePoint Online
• OneDrive for Business
• Microsoft Teams
• Endpoint devices

Microsoft Purview supports additional locations, but the exam scenario will usually identify the workload that contains or transfers the sensitive information.

2. What Information Should Be Detected?

DLP can detect information through mechanisms such as:

• Built-in sensitive information types
• Custom sensitive information types
• Sensitivity labels
• Keywords
• Regular expressions
• Exact data match
• Document properties
• File types
• Contextual conditions

A sensitive information type, or SIT, represents a recognizable data pattern such as a credit card number, tax identifier, or government ID number.

Detection should not rely only on a simple number pattern. Effective sensitive information types may also evaluate supporting evidence, proximity, checksums, keywords, and confidence levels.

3. Under What Conditions Should the Policy Apply?

Conditions determine when a policy rule is considered a match.

Examples include:

• A message contains a credit card number
• A document contains more than a specified number of Social Security numbers
• A file is shared with an external recipient
• A protected item is copied to removable storage
• A user attempts to upload sensitive data to an unapproved cloud application
• The affected user belongs to the HR or legal department
• The recipient is outside the organization
• The content has a specific sensitivity label

4. What Action Should Be Taken?

Possible policy actions include:

• Audit the activity
• Generate an alert
• Display a policy tip
• Block the action
• Block the action but allow an override
• Require a business justification for an override
• Restrict access to content
• Prevent external sharing
• Send an administrator notification
• Apply another protective response supported by the workload

Conditions identify the sensitive activity, while actions determine what happens after the conditions are satisfied. ho Should Be Notified?

Notifications can be directed to:

• The user performing the action
• Security personnel
• Compliance personnel
• Data owners
• Administrators
• Other designated stakeholders

Notifications should be designed to support both user education and incident response.

---

Major DLP Design Use Cases

Regulatory Compliance

DLP policies can help reduce exposure of regulated information.

Payment Card Data

An organization subject to PCI DSS may create a DLP policy that detects credit card numbers and prevents them from being sent outside the organization.

A policy might:

• Detect credit card information
• Identify an external recipient
• Block the email or file transfer
• Notify the sender
• Alert the security or compliance team

Healthcare Information

An organization handling protected health information may detect:

• Patient identifiers
• Medical record information
• Medical terminology
• Insurance information
• Healthcare-related sensitive information types

The policy could prevent the information from being shared through email, Teams, SharePoint, or an unmanaged endpoint activity.

Government and National Identifiers

Policies may detect:

• Social Security numbers
• Tax identifiers
• Passport numbers
• Driver’s license numbers
• National identity numbers

The response should reflect the sensitivity, volume, recipient, and business context.

One identifier in an approved internal workflow may require a different response from a file containing thousands of identifiers being uploaded to personal cloud storage.

---

Internal Corporate Policies

Not every DLP policy is based on a government regulation.

Organizations can create policies to protect internally sensitive information such as:

• Quarterly financial results
• Merger and acquisition information
• Executive communications
• Board documents
• Pricing models
• Sales forecasts
• Product roadmaps
• Proprietary designs
• Source code
• Customer lists

For example, an organization might allow finance executives to share a quarterly report internally but prevent other users from sharing it externally.

This demonstrates an important design principle: DLP policy decisions can consider both the content and the context of the activity.

---

Department-Specific Controls

Some departments handle information that requires stricter protection.

Examples include:

Human Resources

HR may work with:

• Employee records
• Salary data
• Performance reviews
• Medical information
• Background-check results
• Tax forms

Legal

Legal teams may work with:

• Contracts
• Privileged communications
• Active litigation
• Settlement information
• Non-disclosure agreements
• Regulatory investigations

Finance

Finance may handle:

• Banking information
• Financial forecasts
• Earnings information
• Tax records
• Payment information

Policies can be scoped so that the appropriate users can perform approved business activities while unauthorized users are blocked or audited.

---

Geographic and Business-Unit Requirements

DLP policies can reflect geographic or organizational requirements.

Examples include:

• Restricting personal data from being shared with unauthorized regions
• Applying stricter controls to users covered by GDPR-related requirements
• Applying different policies to subsidiaries or business units
• Restricting cross-border transfers
• Applying additional controls to HR, legal, finance, or research departments

The security analyst should not assume that every location, user, or department requires the same policy.

Overly broad policies can disrupt legitimate work. Policies that are too narrow can leave important data unprotected.

---

Endpoint and Device Use Cases

Endpoint DLP extends Microsoft Purview protection to supported onboarded devices.

It can monitor or control activities involving sensitive files, such as:

• Copying files to USB storage
• Printing documents
• Copying and pasting content
• Uploading files through browsers
• Uploading to personal cloud storage
• Accessing files through unauthorized applications
• Moving data to network shares
• Transferring files through other monitored channels

Depending on the rule, the activity can be:

• Audited
• Allowed with a warning
• Blocked
• Blocked with an override
• Reported as an alert

Endpoint DLP is part of Microsoft Purview DLP. Supported devices must be onboarded and capable of communicating with the Microsoft cloud DLP service. Microsoft currently documents support for onboarded Windows 10, Windows 11, and supported macOS devices. rtant Product Distinction

Microsoft Defender for Endpoint can provide the device-onboarding foundation, but DLP policy creation and administration belong to Microsoft Purview.

Do not choose Defender for Endpoint merely because a scenario involves a device. Determine the actual objective:

• Detect malware or isolate a compromised device: Defender for Endpoint
• Prevent a sensitive document from being copied to USB: Microsoft Purview Endpoint DLP
• Correlate the DLP event with endpoint security alerts: Microsoft Defender XDR

---

Communication Oversight and User Education

DLP does not have to block every event.

It can warn users before they complete a risky action.

Policy Tips

A policy tip is an in-context notification informing the user that their activity conflicts with a DLP policy.

A policy tip can:

• Explain why content is sensitive
• Warn the user before sharing
• Link to organizational policy
• Allow the user to report a false positive
• Allow an override
• Require a business justification

Policy tips help transform DLP from a silent enforcement mechanism into a user-education control.

Overrides

An override may be appropriate when the organization wants to permit legitimate exceptions.

For example:

• A financial employee must send regulated information to an approved auditor.
• An HR employee must provide a tax document to an authorized benefits provider.
• The DLP detection is a false positive.

An organization may configure a rule to:

• Prohibit all overrides
• Allow an override
• Require a business justification
• Allow the user to report a false positive

Override activity and justification can be logged and reviewed. Microsoft notes that overrides operate at the rule level and that the policy tip from the most restrictive applicable rule with the highest priority is displayed. rity Consideration

Overrides should not become an easy method of bypassing controls.

The organization should review:

• Who can override
• Which policies allow overrides
• Whether justification is required
• How frequently users override
• Which users generate repeated exceptions
• Whether overrides are reviewed by security or compliance staff

Repeated override activity may indicate a poorly tuned policy, an inefficient business workflow, or intentional policy evasion.

---

DLP Across Microsoft Workloads

DLP with Exchange Online

DLP can inspect Exchange Online email messages and attachments for sensitive information.

A policy might detect:

• Credit card numbers
• Health information
• Employee records
• Financial information
• Government identifiers
• Custom business data

It can also evaluate context, such as whether the recipient is internal or external.

Possible actions include:

• Audit the message
• Warn the sender
• Block the message
• Allow an override
• Require justification
• Generate an alert
• Notify an administrator
• Apply a supported protective action

Example

A user attempts to send a spreadsheet containing customer credit card information to a personal email address.

The DLP policy could:

1. Detect the credit card sensitive information type.
2. Determine that the recipient is external.
3. Block the message.
4. Display a policy tip.
5. Generate a high-severity alert.
6. Notify the compliance team.

SOC Investigation Questions

An analyst should determine:

• Who sent the message?
• Who was the intended recipient?
• Was the recipient authorized?
• Was the message blocked?
• Did the user override the policy?
• What files were attached?
• How many sensitive records were involved?
• Has the user performed similar activities?
• Is there evidence of account compromise?
• Was any information successfully delivered?

---

DLP with SharePoint Online and OneDrive

DLP can evaluate files stored in or shared from SharePoint Online and OneDrive for Business.

Policies can detect sensitive data whether the file is:

• Stored at rest
• Newly uploaded
• Modified
• Shared internally
• Shared externally
• Accessed by an unauthorized user

Possible controls include:

• Restrict external sharing
• Block access
• Prevent download
• Display a warning
• Generate an alert
• Notify the user or administrator

Example

A financial report containing unreleased quarterly results is uploaded to SharePoint and shared through an anonymous link.

A DLP policy could identify the sensitive content and restrict access before the link is used.

SOC Investigation Questions

The analyst should review:

• The file owner
• The site or OneDrive account
• The sensitivity classification
• Existing sharing links
• External users with access
• Download activity
• File modification history
• Whether the policy blocked access
• Whether copies exist elsewhere
• Whether the file was uploaded to another service

---

DLP with Microsoft Teams

DLP can monitor sensitive information in Teams chats and channel messages.

This includes:

• One-to-one chats
• Group chats
• Channel messages
• Communication with guests or external users

A matched message can be blocked or removed from view according to the policy configuration.

Teams Messages Versus Teams Files

This is an important Microsoft-specific distinction.

• A Teams chat or channel message is evaluated through the Teams DLP location.
• A file shared through Teams is stored through SharePoint or OneDrive.

Therefore, protecting a document shared in Teams may require the DLP policy to include SharePoint and OneDrive, not only Teams. Microsoft specifically notes that DLP protection for documents shared with guests through Teams depends on SharePoint and OneDrive being included in the policy. ple

An employee pastes payroll information into the wrong Teams channel.

The DLP policy detects the sensitive information and prevents the message from being displayed.

Another employee uploads a payroll spreadsheet to a Teams channel containing external guests.

The file itself is protected through the associated SharePoint or OneDrive storage location.

---

DLP with Endpoint Devices

Endpoint DLP monitors what users do with sensitive data on onboarded devices.

Examples include:

• Copying a sensitive file to USB
• Printing a protected document
• Uploading a file to personal Dropbox or Google Drive
• Copying data into an unauthorized application
• Moving files to an unapproved location

Example

A developer attempts to upload source-code files from a corporate laptop to a personal cloud-storage account.

Endpoint DLP could:

1. Identify the sensitive file or matching content.
2. Detect the upload destination.
3. Block or warn on the upload.
4. Record the event.
5. Generate an alert for investigation.

SOC Investigation Questions

The analyst should determine:

• Which device was used?
• Which user was signed in?
• What file was involved?
• Which application or browser performed the action?
• What destination was targeted?
• Was the action blocked?
• Did the user override the warning?
• Are there related endpoint or identity alerts?
• Is the device managed and compliant?
• Does the user have a legitimate business reason?

---

Custom and Industry-Specific Protection

Built-in sensitive information types may not identify every form of proprietary data.

Organizations may need custom detection for:

• Engineering schematics
• CAD files
• Source-code patterns
• Internal project names
• Legal case numbers
• Product-development identifiers
• Customer-specific identifiers
• Proprietary document templates
• Research data

Possible detection methods include:

• Custom sensitive information types
• Keywords or keyword dictionaries
• Sensitivity labels
• File properties
• Exact data match
• Document fingerprinting
• File extensions
• Contextual policy conditions

Custom detection should be thoroughly tested because broad keywords can create large numbers of false positives.

---

Microsoft Security Operations Context

DLP Alert Lifecycle

Microsoft describes the DLP alert lifecycle as:

1. Trigger
2. Notify
3. Triage
4. Investigate
5. Remediate
6. Tune

This creates a useful SOC workflow for handling possible data-loss events. 1. Trigger

A DLP alert begins when content or activity matches the conditions of a DLP policy rule.

The rule may detect:

• Sensitive information being shared externally
• Sensitive content being transferred to removable media
• An unauthorized upload
• A policy override
• An excessive volume of protected records
• A prohibited endpoint action

Not every policy match must generate an alert. Alert generation depends on the policy configuration.

---

2. Notify

The policy may notify:

• The affected user
• Security operations
• Compliance staff
• Administrators
• Data owners

User notifications are usually intended to educate or immediately stop the action.

Administrator notifications support investigation and escalation.

---

3. Triage

The analyst determines whether the event is:

• A true positive
• A benign positive
• A false positive
• A confirmed policy violation
• A possible compromised-account event
• A possible insider-risk event
• A legitimate business activity requiring an exception

Initial Triage Questions

• Was the action blocked or completed?
• What sensitive information was detected?
• How much data was involved?
• Was the destination internal or external?
• Is the recipient authorized?
• Did the user override the policy?
• Does the user have a valid business justification?
• Has this user triggered similar alerts?
• Are there related identity, endpoint, or email alerts?
• Is the affected data regulated or business-critical?

Prioritization Factors

Severity should reflect:

• Sensitivity of the data
• Number of affected records
• Whether the data left the organization
• Destination risk
• User risk
• Repeated behavior
• Whether a policy was bypassed
• Whether the account or device appears compromised
• Legal or regulatory impact

A blocked attempt involving one internal document is usually less urgent than a successful upload of thousands of customer records to a personal cloud account.

---

4. Investigate

The investigation should determine:

• What happened
• Who was involved
• Which data was affected
• Where the data originated
• Where the user attempted to send it
• Whether the action succeeded
• Whether additional copies exist
• Whether the activity was accidental or intentional
• Whether a compromised account or device was involved
• Whether other users or systems were affected

Relevant Entities

A DLP investigation may include:

• Users
• Devices
• Email messages
• Mailboxes
• Files
• SharePoint sites
• OneDrive accounts
• Teams conversations
• IP addresses
• Applications
• Browsers
• Cloud-storage destinations
• External recipients

Investigation Tools

The primary tools include:

• Microsoft Defender XDR incident queue
• Microsoft Purview DLP Alerts dashboard
• Activity Explorer
• Content Explorer
• Advanced Hunting, when relevant
• Microsoft 365 audit data

Microsoft recommends the unified Microsoft Defender incident queue for managing DLP alerts when analysts need broader correlation and incident-management capabilities. The Defender portal can group DLP alerts with related Defender for Endpoint or Defender for Office 365 signals. 5. Remediate

Remediation depends on whether the information was actually exposed and why the event occurred.

Possible actions include:

• Remove external sharing
• Revoke a sharing link
• Restrict access to a file
• Delete an exposed message
• Remove a document
• Apply a sensitivity label
• Reset a compromised password
• Disable an account
• Isolate a compromised device
• Quarantine a malicious file
• Require user education
• Escalate to legal, HR, privacy, or compliance
• Preserve evidence
• Open a formal incident-response case

The response should be proportional to the risk.

An accidental internal email should not automatically receive the same response as intentional bulk exfiltration.

---

6. Tune

After the incident is resolved, determine whether the policy worked as intended.

Questions include:

• Did the policy detect the correct data?
• Was the event blocked?
• Did the policy generate too many false positives?
• Was the severity appropriate?
• Were the right teams notified?
• Was the user guidance understandable?
• Should overrides remain available?
• Should the threshold be changed?
• Should additional workloads be included?
• Are exclusions too broad?
• Does the detection logic need refinement?

Policy tuning is part of the security lifecycle, not merely an initial deployment task.

---

Simulation Mode and Safe Deployment

A new DLP policy can disrupt business operations if it is immediately placed into enforcement.

Microsoft recommends a gradual deployment approach:

1. Run the policy in simulation mode without user notifications.
2. Review matches, reports, and expected impact.
3. Tune the detection conditions.
4. Enable policy tips and notifications in simulation.
5. Collect user feedback and false-positive reports.
6. Move to enforcement once the results are acceptable.
7. Continue monitoring after enforcement.

Microsoft’s current terminology uses simulation mode, which replaced the older Test and Test with policy tips states. Simulation evaluates policy behavior without enforcing the configured restrictions. both a technical and change-management control.

---

Exam-Relevant Takeaways

Know the Correct Portal

Use the Microsoft Purview portal to:

• Create DLP policies
• Configure policy locations
• Select sensitive information types
• Configure restrictions
• Configure policy tips
• Configure overrides
• Review the DLP Alerts dashboard
• Investigate data-classification activity

Use the Microsoft Defender portal when the scenario requires:

• Unified incident management
• Correlation with endpoint or email security alerts
• Incident assignment
• Broader entity investigation
• Remediation across users, files, email, and devices
• Advanced Hunting

Use Microsoft Sentinel when the organization requires:

• SIEM-wide correlation
• Centralized monitoring across Microsoft and non-Microsoft sources
• Long-term analytics based on ingested data
• Custom KQL-based detection
• Automation through Sentinel playbooks
• SOC workflows extending beyond Microsoft 365

Match the Workload to the DLP Location

• Sensitive email: Exchange Online
• Stored or shared document: SharePoint or OneDrive
• Teams chat text: Microsoft Teams
• File shared through Teams: SharePoint or OneDrive
• USB, printing, browser upload, or endpoint activity: Endpoint DLP

Know the Difference Between Detection and Enforcement

A policy can:

• Audit only
• Warn
• Block
• Block with override
• Generate an alert

An alert does not necessarily mean the data was successfully exposed.

Always determine whether the action was blocked, overridden, or completed.

Understand Policy Tips

Policy tips provide user-facing warnings and education.

They may also:

• Allow an override
• Require justification
• Allow false-positive reporting

Do not assume every policy tip allows an override.

Understand Endpoint DLP Dependencies

Endpoint DLP requires supported devices to be onboarded.

Defender for Endpoint may provide onboarding and endpoint telemetry, but the data-protection policy remains a Microsoft Purview feature.

Use Simulation Before Enforcement

For a new tenant-wide DLP policy, the safest answer is generally:

1. Test in simulation.
2. Review results.
3. Tune the policy.
4. Introduce notifications.
5. Enforce gradually.

---

Tool / Feature Decision Guide

Scenario	Best Microsoft Security Tool or Feature	Why
Create a policy that blocks credit card numbers from being emailed externally	Microsoft Purview DLP with Exchange Online location	Purview DLP defines the sensitive information, conditions, and enforcement action
Prevent sensitive files from being shared externally from SharePoint	Microsoft Purview DLP with SharePoint location	The policy evaluates stored and shared SharePoint content
Protect a document uploaded through Microsoft Teams	SharePoint and OneDrive DLP locations	Teams files are stored through SharePoint or OneDrive
Block sensitive text pasted into a Teams chat	Microsoft Purview DLP with Teams location	The policy evaluates Teams chat and channel-message content
Prevent copying sensitive files to USB	Microsoft Purview Endpoint DLP	Endpoint DLP monitors and controls device-level file activity
Detect malware on the device used in a data-loss event	Microsoft Defender for Endpoint	Defender for Endpoint investigates endpoint threats and device compromise
Correlate a DLP alert with endpoint and email alerts	Microsoft Defender XDR	Defender XDR groups related alerts and entities into incidents
Review DLP policy violations and associated metadata	Microsoft Purview DLP Alerts dashboard	The dashboard is designed for DLP alerts, events, and policy details
Review historical actions involving labeled or sensitive content	Activity Explorer	Activity Explorer provides activity-focused data for protected content
Examine sensitive content discovered in the environment	Content Explorer	Content Explorer supports content-focused investigation
Warn a user before sensitive data is shared	Policy tip	The warning appears in the user workflow and can provide guidance
Permit a documented business exception	Block with override and business justification	The action is controlled and the justification can be reviewed
Test a new policy without blocking users	DLP simulation mode	Simulation shows likely impact without enforcing restrictions
Create broad SIEM correlation across many vendors	Microsoft Sentinel	Sentinel provides centralized SIEM analytics and KQL-based detection
Investigate a unified Microsoft security incident	Microsoft Defender XDR incident queue	It correlates alerts from Microsoft security and data-protection services

---

DLP Policies vs Defender XDR Incidents

DLP Policy	Defender XDR Incident
Defines what sensitive information should be protected	Groups related security and DLP alerts
Configured in Microsoft Purview	Managed in the Microsoft Defender portal
Contains locations, conditions, exceptions, and actions	Contains alerts, evidence, entities, timelines, and investigation details
Can warn, audit, block, or allow overrides	Supports triage, assignment, investigation, and remediation
Preventive and detective control	Security-operations investigation object

A DLP policy is not an incident.

A policy match may generate an alert, and related alerts may then be grouped into a Defender XDR incident.

---

Policy Tips vs Alerts

Policy Tip	DLP Alert
Presented to the user	Presented to security or compliance personnel
Intended to warn or educate	Intended to initiate review or investigation
May offer an override	Includes policy-match and activity information
Happens in the user workflow	Appears in an alert-management workflow
Can prevent the activity before completion	May represent a blocked or successful activity

---

KQL Notes

No KQL query was demonstrated in this lesson.

The core configuration task is performed through Microsoft Purview DLP policies rather than by writing a KQL query.

KQL may become relevant when an analyst needs to:

• Correlate DLP activity with security events
• Search Defender XDR Advanced Hunting data
• Investigate related device activity
• Examine identity or email behavior
• Build Microsoft Sentinel detections from ingested alerts or logs

For this topic, remember the design principle:

Use DLP policies to identify and control sensitive-data activity. Use hunting tools when you need to investigate broader behavior around the DLP event.

Do not select a KQL hunting query as a replacement for a DLP enforcement policy.

---

Common Exam Traps

Trap 1: Selecting Defender for Endpoint to Configure USB DLP Rules

Defender for Endpoint may help onboard and investigate the device, but Microsoft Purview Endpoint DLP defines the sensitive-data policy.

Trap 2: Selecting Teams Alone for Files Shared in Teams

Teams messages are protected through the Teams DLP location.

Files shared through Teams are stored in SharePoint or OneDrive and require those locations to be included.

Trap 3: Assuming an Alert Means Data Was Lost

The policy may have blocked the action.

First determine:

• Whether the action succeeded
• Whether an override occurred
• Whether the recipient gained access

Trap 4: Enforcing a Broad Policy Immediately

The safer Microsoft pattern is to use simulation mode, review the impact, tune the policy, and then enforce it gradually.

Trap 5: Assuming All Users Can Override

Override behavior is configured per rule.

Some policies may allow:

• No override
• Override with justification
• False-positive reporting
• Other controlled exceptions

Trap 6: Confusing Sensitivity Labels with DLP Policies

A sensitivity label classifies and may protect an item.

A DLP policy monitors activities and responds when content or behavior matches configured conditions.

They can work together, but they are not the same feature.

Trap 7: Using Microsoft Sentinel to Author a DLP Policy

Sentinel is a SIEM and SOAR platform.

DLP policies are created in Microsoft Purview.

Sentinel may receive or correlate relevant security data, but it does not replace Purview DLP enforcement.

Trap 8: Blocking Every Match

The strongest enforcement is not always the best design.

A policy should reflect:

• Data sensitivity
• Business requirements
• Recipient
• destination
• User role
• Volume
• Risk
• Regulatory requirements

Trap 9: Treating Every DLP Alert as Malicious Insider Activity

Many DLP events are accidental.

The analyst must investigate before assigning intent.

Trap 10: Ignoring Policy Tuning

False positives and unnecessary blocking can lead users to distrust the system or create unauthorized workarounds.

Policy tuning is a continuing operational responsibility.

---

Real-World SOC Analyst Notes

Alert Fatigue

A poorly configured DLP policy can generate large numbers of low-value alerts.

Common causes include:

• Thresholds that are too low
• Overly broad keywords
• Missing exceptions
• Policies applied to inappropriate users
• Legitimate business processes that were not considered
• Duplicate or overlapping policies
• Excessive alerting on blocked activity

Alerts should be prioritized based on business risk, not simply the existence of a match.

---

False Positives

False positives are especially common with number-based detection.

For example, a number that resembles a government identifier might actually be:

• A ticket number
• A customer number
• A device serial number
• A purchase-order number
• Test data

Analysts should document recurring false positives and provide that information to the DLP policy owners.

Possible tuning actions include:

• Adjusting confidence levels
• Requiring supporting keywords
• Increasing occurrence thresholds
• Adding justified exceptions
• Using a more precise custom sensitive information type
• Applying exact data match

---

Evidence Preservation

For a serious DLP incident, preserve:

• Alert details
• Policy name
• Matched rule
• User identity
• Device identity
• File name and location
• Hash information, when available
• Recipient or destination
• Timestamp
• Override justification
• Relevant audit events
• Sharing permissions
• Related endpoint, email, or identity alerts
• Actions already taken by the policy

Do not destroy relevant evidence before determining whether legal, privacy, compliance, HR, or law-enforcement review is required.

---

Escalation Paths

Potential escalation teams include:

• Security incident response
• Compliance
• Privacy
• Legal
• Human resources
• Identity team
• Endpoint team
• Messaging team
• SharePoint or collaboration team
• Data owner
• Business management

Escalation should depend on:

• Whether data left the organization
• Regulatory obligations
• User intent
• Amount of data
• Sensitivity
• Scope
• Repeated behavior
• Evidence of compromise

---

Automation Safety

Automated blocking can reduce response time but can also disrupt legitimate work.

Before enforcing a broad policy:

• Establish ownership
• Define exceptions
• Test business workflows
• Use simulation mode
• Define an emergency bypass process
• Monitor false positives
• Document rollback steps
• Confirm help-desk escalation procedures

A tenant-wide DLP change should be managed through change control.

---

Permissions and Separation of Duties

Not every analyst should have permission to:

• Change DLP policies
• View sensitive content
• Override restrictions
• Export investigation evidence
• Remediate users or devices

Use role-based access and least privilege.

An analyst may be permitted to review alerts without being permitted to read the full contents of every sensitive document.

Microsoft documents specific Purview, security, and information-protection roles for access to the DLP Alerts dashboard. Data Retention

Analysts should understand the retention period of each investigation tool.

Microsoft currently documents different retention periods for the Purview DLP Alerts dashboard and Defender XDR incidents. The Purview alert dashboard is intended for DLP-specific operational review, while the Defender incident queue offers longer incident history and broader correlation. er-term retention, organizations may need:

• Microsoft Sentinel
• Audit-retention policies
• Case-management systems
• Evidence repositories
• Regulatory retention processes

---

Cost Considerations

Microsoft Purview DLP functionality depends on licensing and workload support.

Microsoft Sentinel introduces separate cost considerations, especially for:

• Data ingestion
• Retention
• Analytics
• Automation
• Search
• Long-term storage

Do not send every possible event to Sentinel without considering its investigation value and ingestion cost.

A practical design may keep detailed DLP activity in Purview while forwarding high-value incidents or required audit data into the central SIEM.

---

Quick Reference Summary

• DLP means Data Loss Prevention.
• Microsoft Purview DLP identifies sensitive information and controls risky activity.
• Core locations include Exchange, SharePoint, OneDrive, Teams, and endpoint devices.
• Sensitive information can include regulated data, intellectual property, and custom business information.
• A DLP policy contains locations, conditions, actions, notifications, and exceptions.
• Policy actions can audit, warn, block, allow overrides, and generate alerts.
• Policy tips educate users at the time of the risky action.
• Overrides can require a business justification.
• Teams chat text uses the Teams DLP location.
• Files shared through Teams are protected through SharePoint or OneDrive.
• Endpoint DLP can control activities such as USB copying, printing, and cloud uploads.
• Defender for Endpoint may support device onboarding, but DLP policies are managed in Microsoft Purview.
• A DLP alert does not prove that data was successfully exposed.
• Investigate the user, device, data, destination, result, and related security alerts.
• Use the Defender XDR incident queue for unified incident correlation.
• Use simulation mode before enforcing a broad DLP policy.
• Tune policies continuously to reduce false positives and business disruption.
• DLP reduces risk but cannot eliminate every possible exfiltration method.

---

Flashcards

Q: What does DLP stand for?
A: Data Loss Prevention.

Q: Which Microsoft portal is primarily used to create and manage DLP policies?
A: The Microsoft Purview portal.

Q: Which Microsoft platform can correlate DLP alerts with endpoint and email security alerts?
A: Microsoft Defender XDR.

Q: Which DLP location should protect sensitive email messages and attachments?
A: Exchange Online.

Q: Which locations protect files shared through Microsoft Teams?
A: SharePoint Online and OneDrive for Business.

Q: Which location protects text entered into Teams chats and channel messages?
A: Microsoft Teams.

Q: Which feature can block a sensitive file from being copied to a USB drive?
A: Microsoft Purview Endpoint DLP.

Q: What is a policy tip?
A: An in-context notification that warns or educates a user about activity that conflicts with a DLP policy.

Q: Can a policy tip allow an override?
A: Yes, when the DLP rule is configured to allow an override.

Q: What should an analyst determine before concluding that a DLP alert represents data loss?
A: Whether the action succeeded, was blocked, or was overridden.

Q: What mode should generally be used before enforcing a new tenant-wide DLP policy?
A: Simulation mode.

Q: What are the six general stages of the DLP alert lifecycle?
A: Trigger, notify, triage, investigate, remediate, and tune.

Q: Does Defender for Endpoint replace Microsoft Purview Endpoint DLP?
A: No. Defender for Endpoint may support device onboarding and investigation, while Purview defines the DLP policy.

Q: What is the difference between a DLP alert and a Defender XDR incident?
A: A DLP alert represents a policy-related event, while an incident can group that alert with other related security alerts and evidence.

Q: Why should DLP policies be continually tuned?
A: To reduce false positives, avoid unnecessary business disruption, and adapt to changing data and business requirements.

---

Practice Questions

Question 1:

An organization wants to prevent employees from emailing documents containing credit card numbers to external recipients. Users should receive a warning, and an alert should be generated for the compliance team.

Which feature should be configured?

A. A Microsoft Sentinel scheduled analytics rule
B. A Microsoft Purview DLP policy for Exchange Online
C. A Microsoft Defender for Endpoint antivirus policy
D. A Microsoft Entra Conditional Access policy

Correct Answer:
B. A Microsoft Purview DLP policy for Exchange Online

Explanation:
Microsoft Purview DLP can detect credit card information in email messages and attachments, evaluate whether the recipient is external, warn or block the sender, and generate an alert. Sentinel can correlate events but does not provide Exchange DLP enforcement.

---

Question 2:

A user uploads a document containing employee tax information to a Microsoft Teams channel that includes external guests. The organization wants to prevent the guests from opening the file.

Which DLP locations are most important?

A. Microsoft Teams only
B. Exchange Online only
C. SharePoint Online and OneDrive for Business
D. Endpoint devices only

Correct Answer:
C. SharePoint Online and OneDrive for Business

Explanation:
Files shared through Teams are stored in SharePoint or OneDrive. The Teams DLP location protects chat and channel-message content, but document protection depends on the associated file-storage locations.

---

Question 3:

An organization wants to prevent users from copying files containing Social Security numbers to removable USB drives.

Which solution should be used?

A. Microsoft Defender for Identity
B. Microsoft Purview Endpoint DLP
C. Microsoft Defender for Office 365
D. Microsoft Sentinel watchlists

Correct Answer:
B. Microsoft Purview Endpoint DLP

Explanation:
Endpoint DLP can monitor and restrict actions involving sensitive files on onboarded devices, including copying to removable storage.

---

Question 4:

A security administrator has created a DLP policy that could affect thousands of SharePoint documents. The administrator wants to understand its impact before users are blocked.

What should the administrator do first?

A. Enable full enforcement for all users
B. Create a Microsoft Sentinel playbook
C. Run the DLP policy in simulation mode
D. Isolate all devices containing matching documents

Correct Answer:
C. Run the DLP policy in simulation mode

Explanation:
Simulation mode evaluates policy matches without enforcing restrictions. The results can be reviewed and used to tune the policy before production enforcement.

---

Question 5:

A DLP alert shows that a user attempted to upload a sensitive file to personal cloud storage. The same user has a suspicious sign-in alert and a malware alert on the device.

Where should the analyst perform the unified investigation?

A. Microsoft Purview sensitivity-label configuration
B. Microsoft Defender XDR incident queue
C. Microsoft Entra user-registration settings
D. Exchange mail-flow rules

Correct Answer:
B. Microsoft Defender XDR incident queue

Explanation:
Microsoft Defender XDR can correlate DLP, identity, endpoint, and other security alerts into a unified incident. Purview remains the source of the DLP policy and detailed data-protection information.