Microsoft Purview DLP Policy Priority and Rule Precedence – SC-200 Study Guide | Microsoft SC-200 Security Operations Analyst

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.

Microsoft Purview DLP Policy Priority and Rule Precedence – SC-200 Study Guide

Watch this lesson