Study guide
Technical reference and lesson notes
Purpose of This Lesson
This lesson explains how Microsoft Purview Data Loss Prevention determines which policy or rule takes precedence when multiple DLP controls apply to the same content or user activity.
The two central concepts are:
- DLP policy priority is determined by its numerical position.
- When multiple DLP rules apply, the most restrictive applicable action takes effect.
These concepts matter for the SC-200 exam because a Security Operations Analyst must understand why a DLP event was allowed, audited, reported, or blocked. Analysts may also need to determine which policy and rule generated an alert, investigate the affected user or content, and recommend changes when overlapping policies produce unexpected results.
Key Concepts
Microsoft Purview Data Loss Prevention
Microsoft Purview Data Loss Prevention helps organizations identify and protect sensitive information across supported Microsoft services and endpoints.
DLP policies can detect sensitive information such as:
- Financial data
- Government identification numbers
- Health information
- Credentials
- Personally identifiable information
- Organization-specific sensitive data
A policy can respond by:
- Auditing the activity
- Displaying a policy tip
- Sending an email notification
- Generating an alert
- Sending an incident report
- Restricting or blocking the activity
The action depends on the conditions and actions configured in the matching DLP rule.
A typical navigation path is:
Microsoft Purview portal → Solutions or Information Protection → Data Loss Prevention → Policies
Portal labels and navigation can change, but DLP policy administration remains part of Microsoft Purview.
DLP Policies Contain One or More Rules
A DLP policy is a container for one or more rules.
Each rule can include:
- Conditions that identify sensitive information
- Thresholds for the number of detected instances
- User or group scope
- Content locations
- Exceptions
- User notifications
- Policy tips
- Alert settings
- Enforcement actions
A single policy may use different rules for different levels of risk.
For example, a financial-data template may create:
- A low-volume rule for a small number of sensitive-information instances
- A high-volume rule for a larger number of instances
The lower-volume rule may notify the user, while the higher-volume rule may generate alerts, send incident reports, or apply stronger restrictions.
DLP Policy Priority
When more than one DLP policy could apply, Microsoft Purview uses the policies’ assigned priority order.
For DLP policies:
A lower priority number represents a higher policy priority.
For example:
| DLP Policy | Priority Number | Relative Priority |
|---|---|---|
| UK Financial Data | 0 | Highest |
| US Financial Data | 1 | Lower than priority 0 |
| General Sensitive Data | 2 | Lower than priorities 0 and 1 |
A policy with priority 0 has higher precedence than a policy with priority 1.
This numbering convention can be confusing because other Microsoft features may use different priority models. Do not assume that a higher number always means a higher priority.
Reordering DLP Policies
Administrators can change policy priority from the DLP policy list.
Typical options include:
- Move up
- Move down
- Move to highest priority
- Move to lowest priority
Moving a policy to the highest position gives it the lowest numerical priority value, normally 0.
Important Distinction
Policy priority answers this question:
Which DLP policy has higher precedence when policies overlap?
It does not necessarily answer:
Which specific action will be enforced when multiple rules match?
Rule evaluation must also be considered.
Rules Within a DLP Policy
A DLP policy can contain multiple rules that evaluate different conditions or thresholds.
A financial-data policy may include rules similar to the following:
| Rule | Sensitive-Information Count | Example Response |
|---|---|---|
| Low-volume detection | 1–4 instances | Notify the user through email or a policy tip |
| High-volume detection | 5 or more instances | Notify the user, generate alerts, and send incident reports |
The threshold is based on how many qualifying sensitive-information instances are detected in the evaluated content or activity.
A high-volume rule is not simply another name for a high-severity incident. It is a rule whose conditions require a larger number of matching instances.
Most Restrictive Rule Behavior
Multiple DLP rules may apply to the same content or activity.
When matching rules produce different enforcement outcomes, the most restrictive applicable action takes effect.
For example:
- Rule A displays a warning but allows the activity.
- Rule B blocks the activity.
- Both rules apply to the same action.
The blocking action is more restrictive, so it governs the enforcement result.
This principle helps prevent a less restrictive rule from weakening protection established by another applicable rule.
Example
Assume a document contains multiple financial identifiers.
One rule:
- Detects at least one financial identifier
- Displays a policy tip
- Allows the user to continue
Another rule:
- Detects five or more identifiers
- Blocks external sharing
- Generates an alert
When the document contains six matching identifiers, the high-volume rule applies and the more restrictive blocking behavior is enforced.
Policy Priority Versus Rule Restrictiveness
Policy priority and rule restrictiveness are related but separate concepts.
| Concept | What It Controls |
|---|---|
| Policy priority | The precedence assigned to DLP policies |
| Rule conditions | Whether a particular rule matches |
| Rule actions | What happens after the rule matches |
| Most restrictive behavior | The effective enforcement result when applicable rules conflict |
Do not reduce DLP evaluation to a single statement such as “the first matching rule wins.”
An analyst should review:
- Which policies applied
- The priority of those policies
- Which rules matched
- The conditions and thresholds in each rule
- The actions configured in those rules
- The final action enforced
DLP Policy Simulation
A new DLP policy can be placed in simulation mode before full enforcement.
Simulation allows administrators to evaluate how the policy would behave without immediately applying its full enforcement actions.
Simulation is useful for:
- Identifying false positives
- Estimating how often rules will match
- Reviewing affected users and locations
- Validating sensitive-information types
- Determining whether thresholds are appropriate
- Evaluating operational impact
- Preparing users and support teams for enforcement
A policy should generally be validated in simulation before it is broadly enforced, especially when it can block business activity.
Simulation does not mean that the policy is fully protecting data. It is primarily a testing and evaluation state.
Microsoft Security Operations Context
How DLP Fits Into a SOC Workflow
DLP is primarily configured in Microsoft Purview, but DLP alerts and events can become part of a broader security operations workflow.
A typical workflow may include:
- A user attempts to share, copy, email, upload, or otherwise handle sensitive information.
- Microsoft Purview evaluates applicable DLP policies.
- One or more DLP rules match the activity.
- The effective action is determined.
- The user may receive a policy tip or notification.
- An alert or incident report may be generated.
- An analyst reviews the activity and determines whether it was legitimate, accidental, negligent, or malicious.
- The analyst documents the outcome and recommends remediation or policy tuning.
Triage a DLP Alert
When a DLP alert is generated, the analyst should identify:
- The affected user
- The sensitive-information type detected
- The number of detected instances
- The content or activity involved
- The affected Microsoft 365 or endpoint location
- The policy that matched
- The specific rule that matched
- The action taken
- Whether the content was blocked, overridden, or allowed
- Whether similar activity has occurred previously
The policy name alone is not enough. The analyst must identify the matching rule because different rules within the same policy may apply different thresholds and actions.
Investigate the User and Activity
The analyst should determine whether the activity is consistent with the user’s job responsibilities.
Relevant questions include:
- Does the user normally access this type of information?
- Was the destination internal or external?
- Was the recipient authorized?
- Was the activity performed from a managed device?
- Did the user override a policy warning?
- Has the user triggered similar alerts before?
- Was a large volume of sensitive data involved?
- Did the activity occur during unusual hours?
- Are there related identity, endpoint, email, or cloud alerts?
The DLP event may need to be correlated with information from:
- Microsoft Defender XDR
- Microsoft Defender for Endpoint
- Microsoft Defender for Office 365
- Microsoft Defender for Cloud Apps
- Microsoft Entra ID
- Microsoft Sentinel
Microsoft Purview remains the primary location for configuring the DLP policy itself.
Determine Scope and Impact
An analyst should determine whether the event was isolated or part of a broader pattern.
Scope may include:
- Additional files
- Other emails or messages
- Other recipients
- Additional cloud storage locations
- Other devices used by the same person
- Other users accessing the same sensitive data
- Repeated policy overrides
- Similar alerts from the same department
A single accidental email may require user coaching. Repeated transfers of sensitive information to unauthorized destinations may require escalation and containment.
Containment and Remediation
The correct response depends on the activity and the available controls.
Possible actions include:
- Confirming that the DLP policy blocked the activity
- Removing an externally shared link
- Restricting access to the affected content
- Revoking active sessions
- Isolating a device when endpoint compromise is suspected
- Escalating to the compliance, legal, privacy, or insider-risk team
- Adjusting a rule threshold
- Adding a documented exception
- Changing notification language
- Increasing enforcement after simulation
- Retraining the affected user
The response should be proportional to the risk. A legitimate business process should not be disrupted without validating the context.
Document Findings
A useful DLP investigation record should include:
- Alert or event date and time
- Affected user
- Content and location involved
- Sensitive-information type
- Detected instance count
- Matching policy
- Matching rule
- Policy priority
- Action taken by Purview
- User override information
- Analyst findings
- Scope of exposure
- Escalation decisions
- Remediation steps
- Policy-tuning recommendations
Documenting the exact policy and rule is especially important when overlapping policies exist.
Improve Future Detection
After resolving an alert, the SOC and compliance teams should determine whether the policy requires improvement.
Possible adjustments include:
- Changing instance-count thresholds
- Narrowing the users or locations in scope
- Adding exceptions for approved workflows
- Increasing enforcement for high-risk activity
- Reducing unnecessary alerts
- Updating sensitive-information types
- Testing changes in simulation
- Reordering policy priority
- Improving policy-tip instructions
Policy tuning should reduce false positives without creating gaps in protection.
Exam-Relevant Takeaways
Remember the following for the SC-200 exam:
- Microsoft Purview is the primary tool for creating and managing DLP policies.
- DLP policies can contain multiple rules.
- A lower DLP policy priority number means a higher priority.
- Priority 0 represents the highest policy position.
- Administrators can move policies up, down, to the highest priority, or to the lowest priority.
- Do not assume that DLP priority numbering behaves like every other Microsoft feature.
- DLP rules can use different sensitive-information instance thresholds.
- Low-volume and high-volume rules can apply different actions.
- Multiple rules may apply to the same activity.
- When rule actions conflict, the most restrictive applicable action governs the enforcement result.
- A notification or policy tip does not necessarily mean that the activity was blocked.
- Simulation should be used to evaluate a policy before broad enforcement.
- Microsoft Sentinel analytics rules are not used to configure Microsoft Purview DLP enforcement.
- When investigating an alert, identify both the policy and the matching rule.
- Policy priority and rule restrictiveness are separate evaluation concepts.
Tool / Feature Decision Guide
| Scenario | Best Microsoft Security Tool or Feature | Why |
|---|---|---|
| Create or modify a DLP policy | Microsoft Purview Data Loss Prevention | Purview provides DLP policy, rule, scope, notification, and enforcement configuration |
| Determine which DLP policy has the highest precedence | DLP policy priority list | The lowest numerical priority represents the highest policy priority |
| Place a policy above all other policies | Move to highest priority | This places the policy at the top of the DLP priority order, normally priority 0 |
| Test a DLP policy without immediately enforcing all actions | DLP simulation mode | Simulation reveals matches and possible impact before full deployment |
| Apply different responses based on the number of sensitive-data instances | Multiple rules within the DLP policy | Each rule can use a different instance-count threshold and response |
| Resolve overlapping rules with different enforcement actions | Most restrictive applicable action | The stricter matching action governs the effective enforcement result |
| Display guidance to a user during a DLP event | Policy tip | A policy tip informs the user about the policy and the detected activity |
| Notify security or compliance personnel | DLP alert or incident report | These features provide information for investigation and escalation |
| Configure SIEM correlation across multiple security products | Microsoft Sentinel | Sentinel correlates ingested security data but does not replace Purview DLP policy configuration |
| Investigate related endpoint compromise | Microsoft Defender for Endpoint | Endpoint telemetry can determine whether the DLP event is associated with malicious device activity |
| Investigate related identity compromise | Microsoft Entra ID and Defender for Identity | These tools provide identity, sign-in, and account-risk context |
| Investigate sensitive information sent through email | Microsoft Purview DLP and Defender for Office 365 | Purview evaluates DLP conditions, while Defender for Office 365 provides email-threat context |
KQL Notes
This lesson does not use Kusto Query Language.
DLP policy priority and rule actions are configured through Microsoft Purview rather than through a KQL query.
KQL may still be useful in a broader SOC investigation when DLP-related data has been made available to Microsoft Sentinel or another queryable Microsoft security experience. However, the SC-200 concept covered here is policy and rule evaluation, not query construction.
Do not choose a KQL hunting query when the scenario specifically asks how to:
- Reorder DLP policies
- Change DLP rule thresholds
- Configure policy tips
- Enable simulation
- Define DLP enforcement actions
Those tasks belong in Microsoft Purview DLP.
Common Exam Traps
Assuming the Highest Number Has the Highest Priority
For DLP policies, the opposite is true.
Priority 0 is higher than priority 1.
Confusing Policy Priority With Rule Thresholds
Policy priority controls the order of policies.
A rule threshold determines whether a rule matches, such as:
- One to four sensitive-information instances
- Five or more sensitive-information instances
These are separate concepts.
Assuming Only One Rule Can Match
More than one rule may apply to the same content or activity.
The effective result must account for the most restrictive applicable action.
Assuming the First Matching Rule Always Wins
DLP evaluation should not be treated as a simple first-match firewall rule set.
Review all applicable rules and their enforcement actions.
Confusing a Notification With a Block
A rule may notify the user without preventing the action.
Always inspect the rule’s configured enforcement action.
Treating Simulation as Full Enforcement
Simulation helps evaluate the effect of a policy.
It does not mean the policy is applying every configured protective action in production.
Choosing Microsoft Sentinel to Configure DLP
Microsoft Sentinel can help correlate and investigate security data.
DLP policies, thresholds, priority, and enforcement actions are configured in Microsoft Purview.
Assuming High Volume Automatically Means High Severity
A high-volume rule is based on a larger number of matching sensitive-information instances.
The final severity and business risk still depend on the content, destination, user, and configured response.
Ignoring Overlapping Policies
An analyst who reviews only one policy may misunderstand why a particular action occurred.
Check policy priority and all applicable rules.
Real-World SOC Analyst Notes
Alert Fatigue
Poorly tuned DLP policies can generate a large number of alerts for legitimate business activity.
Common causes include:
- Thresholds that are too low
- Broad policy scope
- Sensitive-information types with frequent false positives
- Missing exceptions for approved applications or workflows
- Alerts generated for low-risk activity
Simulation should be used to estimate alert volume before full deployment.
False Positives
A detected pattern does not always represent actual sensitive data.
Analysts should validate:
- The matched sensitive-information type
- The confidence level
- Supporting keywords
- The number of detected instances
- The surrounding content
- The business context
A false positive should lead to careful tuning rather than immediately disabling the policy.
Investigation Quality
The quality of a DLP investigation depends on identifying the exact rule that matched.
The analyst should not document only:
“The financial-data DLP policy triggered.”
A stronger record would state:
- The policy name
- The policy priority
- The matching high-volume or low-volume rule
- The detected instance count
- The action taken
- Whether the user was allowed to override it
- Whether sensitive data left the organization
Escalation Paths
DLP events may require coordination with:
- Compliance
- Privacy
- Legal
- Human resources
- Insider-risk teams
- Data owners
- Messaging administrators
- Endpoint administrators
- Identity teams
- Cloud security teams
A technically successful block can still represent an attempted policy violation that requires further review.
Evidence Preservation
Preserve sufficient evidence to explain:
- What the user attempted
- What data was detected
- Which destination was involved
- Which policy and rule applied
- What Purview did in response
- Whether the user attempted an override
- Whether the activity succeeded
Avoid unnecessarily copying sensitive content into tickets or unsecured investigation notes.
Automation Safety
Automated responses should be proportional to the confidence and impact of the detection.
Automatically blocking sensitive-data transfers may be appropriate for high-confidence scenarios. Automatically disabling a user account for every DLP alert may be too disruptive.
Test automation and enforcement through simulation, pilot groups, and change control.
Change Control
Changes to DLP priority or rule actions can have tenant-wide consequences.
Before modifying a policy:
- Document the current configuration
- Identify overlapping policies
- Review policy scope
- Use simulation
- Notify affected support teams
- Define rollback steps
- Monitor alert and support-ticket volume
Reordering a policy can alter how overlapping controls behave even when the rule definitions are unchanged.
Access Permissions
Only authorized administrators should be able to change DLP policies.
SOC analysts may have sufficient access to investigate alerts without having permission to modify policies. Separate investigation access from policy-administration access where appropriate.
Data Retention and Costs
Microsoft Purview retains DLP-related information according to the applicable Microsoft service, licensing, audit, and retention configuration.
If DLP-related data is also sent to Microsoft Sentinel, consider:
- Data ingestion volume
- Workspace retention
- Query performance
- Duplicate telemetry
- Long-term storage requirements
Do not ingest unnecessary data into Sentinel solely because it is available.
Quick Reference Summary
- Microsoft Purview manages DLP policies.
- A DLP policy can contain multiple rules.
- Lower DLP priority number = higher policy priority.
- Priority 0 is the highest priority.
- Policies can be moved up, down, to the top, or to the bottom.
- Rules can use different sensitive-information count thresholds.
- A low-volume rule may notify the user.
- A high-volume rule may generate alerts or stronger enforcement.
- Multiple rules can apply to one activity.
- The most restrictive applicable action takes effect.
- Notification does not automatically mean blocking.
- Simulation helps validate a policy before enforcement.
- Investigate both the policy and the matching rule.
- Use Purview—not Sentinel—to configure DLP enforcement.
Flashcards
Q: Which Microsoft portal is used to configure DLP policies?
A: Microsoft Purview.
Q: In a Microsoft Purview DLP policy list, does a lower or higher number represent higher priority?
A: A lower number represents higher priority.
Q: What is normally the highest DLP policy priority number?
A: Priority 0.
Q: What happens when a DLP policy is moved to the highest priority?
A: It is moved to the top of the policy order and assigned the lowest priority number.
Q: Can a DLP policy contain more than one rule?
A: Yes. A policy can contain multiple rules with different conditions, thresholds, and actions.
Q: What may distinguish a low-volume rule from a high-volume rule?
A: The number of detected sensitive-information instances.
Q: What happens when multiple applicable DLP rules have conflicting actions?
A: The most restrictive applicable action takes effect.
Q: Does displaying a policy tip always block the user’s activity?
A: No. A policy tip may only notify or warn the user.
Q: Why should a DLP policy be placed in simulation mode?
A: To evaluate matches, false positives, alert volume, and operational impact before full enforcement.
Q: Which feature would you use to define a DLP rule’s sensitive-information threshold?
A: The rule configuration inside the Microsoft Purview DLP policy.
Q: Should Microsoft Sentinel analytics rules be used to reorder Purview DLP policies?
A: No. DLP policy priority is managed in Microsoft Purview.
Q: What should an analyst identify when investigating a DLP alert?
A: The affected user, sensitive-information type, instance count, policy, matching rule, location, destination, and action taken.
Q: Are policy priority and rule restrictiveness the same concept?
A: No. Policy priority orders policies, while rule restrictiveness affects the final enforcement action.
Practice Questions
Question 1:
Your organization has two Microsoft Purview DLP policies that can apply to financial documents. Policy A has priority 0, and Policy B has priority 1.
Which policy has the higher priority?
A. Policy A
B. Policy B
C. Both policies have equal priority
D. The policy containing the largest number of rules
Correct Answer:
A. Policy A
Explanation:
Microsoft Purview DLP policies use lower numbers for higher priority. Priority 0 is higher than priority 1.
Question 2:
A DLP policy contains two applicable rules. One rule displays a warning and allows the user to continue. The other rule blocks the activity.
What should you expect?
A. The warning rule is applied because it is less disruptive
B. The blocking rule is applied because it is more restrictive
C. Neither rule is applied because they conflict
D. The user chooses which rule to apply
Correct Answer:
B. The blocking rule is applied because it is more restrictive
Explanation:
When multiple applicable DLP rules produce conflicting outcomes, the most restrictive applicable action governs the enforcement result.
Question 3:
You are preparing to deploy a new DLP policy that can block external sharing. You need to identify false positives and estimate the impact before enforcing the policy.
What should you do first?
A. Create a Microsoft Sentinel automation rule
B. Place the DLP policy in simulation mode
C. Move the DLP policy to priority 0
D. Disable all existing DLP policies
Correct Answer:
B. Place the DLP policy in simulation mode
Explanation:
Simulation allows administrators to review policy matches and operational impact before enabling full enforcement.
Question 4:
A financial-data DLP policy contains one rule for one to four sensitive-information instances and another rule for five or more instances.
What is the primary purpose of this design?
A. To assign policies to different Microsoft Sentinel workspaces
B. To apply different responses based on the volume of sensitive information
C. To determine which users receive Microsoft Defender licenses
D. To change the retention period of audit data
Correct Answer:
B. To apply different responses based on the volume of sensitive information
Explanation:
Separate thresholds allow the organization to use a less disruptive response for low-volume activity and stronger alerts or enforcement for higher-volume activity.
Question 5:
A security administrator needs to change which DLP policy has precedence over another overlapping policy.
Where should the administrator make the change?
A. Microsoft Defender XDR incident queue
B. Microsoft Sentinel analytics rules
C. Microsoft Purview DLP policy list
D. Microsoft Defender for Endpoint device inventory
Correct Answer:
C. Microsoft Purview DLP policy list
Explanation:
DLP policy priority is managed in Microsoft Purview. Defender XDR and Sentinel may assist with investigation and correlation but do not control Purview DLP policy order.