Adaptive Protection: Risk Levels Meet DLP

The bridge between risk and enforcement

How Adaptive Protection works end-to-end

Step	Component	What Happens
1	Insider Risk Management	Monitors user behaviour — file downloads, email patterns, USB usage, resignation signals
2	Risk scoring	IRM calculates a risk score based on cumulative indicators and sequences
3	Risk level assignment	Users are assigned: Elevated, Moderate, or Minor risk
4	DLP condition	DLP policies use “User’s risk level for Adaptive Protection” as a condition
5	Dynamic enforcement	DLP applies the action configured for that user’s current risk level
6	Automatic adjustment	As behaviour changes, risk levels update and DLP enforcement adjusts automatically

Risk levels explained

Level	Behaviour Pattern	Typical Duration	Example
Elevated	Significant risk indicators — bulk data movement, multiple policy triggers, departure + exfiltration	Days to weeks (depends on behaviour change)	Employee downloaded 500 files after submitting resignation
Moderate	Some risk indicators above baseline — unusual sharing volume, minor policy matches	Days to weeks	User shared 3x more files externally than normal this week
Minor	Within normal behaviour patterns or very slight anomalies	Default for most users	User’s activity is within baseline parameters

How risk levels are calculated

Risk levels are not binary. IRM uses a scoring model that considers:

• Activity volume — how much data is being moved
• Activity type — downloading vs sharing vs printing
• Cumulative patterns — single event vs sustained behaviour
• Triggering events — resignation, PIP, security incident
• Sequence detection — download → rename → upload pattern

Adaptive Protection shifts from uniform enforcement to risk-proportional security

Feature	Without Adaptive Protection	With Adaptive Protection
DLP enforcement	Same for ALL users — one-size-fits-all	Varies by user risk level — proportional
User experience	Low-risk users face same blocks as high-risk	Low-risk users get warnings; high-risk get blocks
False positive impact	High — legitimate users frequently blocked	Low — only elevated-risk users face strict controls
Admin effort	Manual exceptions for trusted users	Automatic — risk-level changes trigger enforcement changes
Security posture	Uniform but may be too loose or too strict	Right-sized — tight for risky users, light for trusted users

Configuring Adaptive Protection

Step 1: Enable in Insider Risk Management

In Purview portal → Insider Risk Management → Adaptive Protection:

• Turn on Adaptive Protection
• Select which IRM policies feed risk levels (typically all active policies)
• Configure risk level thresholds — what score = elevated, moderate, minor

Step 2: Configure risk level conditions in DLP

Edit or create DLP policies and add the condition: “User’s risk level for Adaptive Protection is…” → select Elevated, Moderate, or Minor

Step 3: Set different actions per risk level

DLP Policy: “Protect Financial Data”	Minor Risk	Moderate Risk	Elevated Risk
1-4 credit card matches	Audit only	Warn	Block with override
5+ credit card matches	Warn	Block with override	Block (no override)
Confidential label + external share	Warn	Block with override	Block + alert security

Timeframes and reassessment

Setting	Default	Configurable?
Risk level retention	Risk levels persist while behaviour continues	Yes — configure how quickly levels decay
Reassessment frequency	Continuous — updated as new activity occurs	Built-in — no manual configuration needed
Time to initial assessment	7+ days of activity data before first risk assignment	Fixed — cannot be accelerated

💡 Exam tip: Adaptive Protection prerequisites

For Adaptive Protection to work:

1. At least one active Insider Risk policy must be running
2. Users need 7+ days of activity data for initial risk assessment
3. DLP policies must include the risk level condition — it’s not automatic
4. Licensing: E5, E5 Compliance, or E5 Insider Risk Management

A common exam trap: “Adaptive Protection is enabled but DLP is not applying different actions.” The answer is usually that the DLP policy hasn’t been updated to include the risk level condition.

💡 Scenario: Marcus deploys Adaptive Protection at NovaTech

NovaTech’s DLP policy currently blocks all external sharing of source code. But this frustrates the 95% of developers who share legitimately (code reviews, open-source contributions, client demos).

Marcus deploys Adaptive Protection:

• Minor risk developers (95%): Warn with policy tip when sharing code externally
• Moderate risk (4%): Block with override — provide justification to proceed
• Elevated risk (1%): Hard block — no override, alert security team

Result: Developer satisfaction improves dramatically. Security actually improves because the 1% of truly risky users face stricter controls than before.

Question

What are the three prerequisites for Adaptive Protection to assign risk levels?

Click or press Enter to reveal answer

Answer

1. At least one active Insider Risk Management policy. 2. Users need 7+ days of activity data. 3. DLP policies must include the 'User's risk level for Adaptive Protection' condition. Without all three, risk-based DLP enforcement cannot function.

Click to flip back

Question

How does Adaptive Protection reduce DLP false positives?

Click or press Enter to reveal answer

Answer

By applying strict DLP enforcement only to high-risk users. The 95%+ of users with minor risk get warnings instead of blocks, dramatically reducing false positive disruptions. Meanwhile, the small percentage of users showing risky behaviour face proportionally stricter controls.

Click to flip back

Question

A DLP policy uses Adaptive Protection. A user moves from 'elevated' to 'minor' risk. What happens to their DLP enforcement?

Click or press Enter to reveal answer

Answer

It automatically adjusts. The user will now experience the lighter DLP actions configured for the 'minor' risk level (e.g., warn instead of block). No admin intervention is needed — the change is dynamic and continuous.

Click to flip back

Knowledge Check

Atlas Global enabled Adaptive Protection two days ago. Zara configured a DLP policy with different actions per risk level. But all users are experiencing the same 'warn' action, regardless of their behaviour. What is the most likely cause?

AAdaptive Protection has a bug and needs to be reinstalledBUsers need at least 7 days of activity data before risk levels are assigned — the system is still collecting baseline dataCThe DLP policy is overriding Adaptive Protection settingsDZara needs to manually assign risk levels to each user

Check Answer

🎬 Video coming soon

---

Next up: Purview Audit: Investigate & Retain — track every action in your Microsoft 365 tenant with Audit Standard and Audit Premium.