DLP: Precedence & Adaptive Protection
When multiple DLP rules match the same content, which one wins? Understand rule and policy precedence, and how Adaptive Protection dynamically adjusts DLP enforcement based on insider risk levels.
Why precedence matters
Imagine two security guards at the same door with different instructions.
Guard A says “let employees through with ID.” Guard B says “block everyone — the building is locked down.” Who wins? You need clear rules about which instruction takes priority.
The same happens with DLP. When an email matches Rule 1 (warn) AND Rule 2 (block), which action applies? Microsoft Purview has a clear precedence system: the most restrictive action wins. If one rule says warn and another says block, the content is blocked.
Adaptive Protection adds a twist — DLP enforcement can change dynamically based on a user’s risk level. A trusted employee gets a warning. A high-risk employee (flagged by Insider Risk Management) gets a hard block — for the same content.
Rule precedence within a policy
Each DLP policy can contain multiple rules. Rules are evaluated in priority order (configurable):
| Priority | Rule Name | Condition | Action |
|---|---|---|---|
| 0 (highest) | Block bulk export | 50+ credit cards | Hard block |
| 1 | Block external sharing | 5+ credit cards, external recipient | Block with override |
| 2 | Warn on any detection | 1+ credit card | Warn with policy tip |
The precedence rules
- All matching rules are evaluated — not just the first match
- The most restrictive action wins — block beats warn beats audit
- User notifications from all matching rules are combined — user sees all relevant tips
- Incident reports from all matching rules are generated — admin sees all matches
Key concept: DLP does NOT stop evaluating after the first match. All matching rules contribute to the final enforcement decision.
Policy precedence across multiple policies
When content matches rules in multiple DLP policies, the system combines all matching rules:
| Policy | Rule Matched | Action |
|---|---|---|
| ”Protect Credit Cards” | 5+ credit card numbers | Block with override |
| ”Protect PII” | 1+ SSN | Warn |
| ”Financial Compliance” | Confidential label + external sharing | Block |
Result: The content is blocked (most restrictive action from any matching rule across all policies). The user sees notifications from all three matches.
Exam tip: most restrictive wins
The exam frequently tests DLP precedence. The core rule is simple: the most restrictive action wins.
If two rules match:
- Rule A says “warn” and Rule B says “block” → block wins
- Rule A says “audit only” and Rule B says “block with override” → block with override wins
- Rule A says “block” and Rule B says “block with override” → block wins (no override available)
The precedence of actions from most to least restrictive: Block > Block with override > Warn > Audit only
Adaptive Protection — risk-based DLP
Adaptive Protection connects Insider Risk Management (Domain 3) to DLP. Instead of treating all users equally, DLP responds proportionally to each user’s risk level.
How it works
| Step | What Happens |
|---|---|
| 1. Insider Risk assigns risk levels | Based on user behaviour (file downloads, email patterns, resignation signals) |
| 2. Risk levels | Elevated (highest risk), Moderate, Minor |
| 3. DLP policy uses risk as a condition | A DLP rule can say “if user is elevated risk AND content matches SIT → hard block” |
| 4. Dynamic enforcement | As risk level changes, DLP enforcement changes automatically |
Adaptive Protection example
| User Risk Level | Content: 1 credit card number | Content: 10+ credit card numbers |
|---|---|---|
| Minor | Audit only | Warn |
| Moderate | Warn | Block with override |
| Elevated | Block with override | Hard block |
The same DLP policy, but enforcement scales with risk. A trusted employee gets a gentle nudge. A user showing risky behaviour gets a hard stop.
Configuring Adaptive Protection in DLP
- Enable Adaptive Protection in Insider Risk Management settings
- Define risk level thresholds — what behaviours trigger each level
- Create or edit DLP policies — add “User’s risk level for Adaptive Protection” as a condition
- Configure actions per risk level — different actions for elevated vs moderate vs minor
Scenario: Priya deploys Adaptive DLP at Meridian
Priya’s current DLP policy blocks all credit card sharing externally. But this generates complaints from the wealth management team, who legitimately share transaction data with clients.
With Adaptive Protection:
- Minor risk (most users): Warn with policy tip when sharing credit card data externally
- Moderate risk (flagged users): Block with override — require justification
- Elevated risk (departing employees, users with data exfiltration signals): Hard block — no override, immediate alert to security team
Result: 90% of users experience a lighter policy. The 10% showing risky behaviour face stricter controls. Complaints drop. Security improves.
Prerequisites for Adaptive Protection in DLP
| Requirement | Detail |
|---|---|
| Insider Risk Management | Must be configured with at least one active policy |
| Risk levels | Users must be assigned risk levels (requires 7+ days of activity data) |
| Licensing | E5, E5 Compliance, or E5 Insider Risk Management |
| DLP policy | Must include “User’s risk level for Adaptive Protection” as a condition |
At Meridian Financial, an email matches two DLP rules: Rule A (from the PCI policy) says 'warn with policy tip' and Rule B (from the financial compliance policy) says 'block with override'. What happens?
Priya enabled Adaptive Protection and configured DLP to block with override for elevated-risk users who share credit card data. A wealth management analyst (currently at 'minor' risk level) shares a document containing 3 credit card numbers externally. The DLP rule for minor-risk users is set to 'warn'. What happens?
Next up: Endpoint DLP: Setup & Configuration — extend DLP to Windows and macOS devices where data physically lives.