Adaptive Protection: the dynamic layer across DLP, Conditional Access, and Retention

Every DLP policy you deploy today treats all users identically. The same rules, the same restrictions, the same friction - whether someone is a model employee or actively exfiltrating data.

This creates a lose-lose situation. Make policies strict enough to catch bad actors, and you frustrate 98% of your workforce who are doing nothing wrong. Make them permissive enough to let people work, and the 2% who are actually risky walk right through.

Most organisations land somewhere in the middle. Policies that are too loose for real threats and too tight for normal work. Users learn to work around them. Security teams drown in false positives. Nobody is happy.

Adaptive Protection solves this by making controls context-aware. Instead of one policy for everyone, the controls automatically adjust based on each user's actual risk profile. High-risk users get strict enforcement. Everyone else barely notices the policies exist.

Adaptive Protection sits between Insider Risk Management and three enforcement tools: DLP, Conditional Access, and Data Lifecycle Management.

The flow is straightforward. IRM's machine learning models continuously monitor user activity across your M365 environment - file downloads, sharing patterns, email behaviour, device activity. Based on that activity, each user gets assigned one of three risk levels:

Elevated - users with high severity alerts, multiple high-severity sequence insights, or confirmed high-severity alerts. These are your "take action now" users.

Moderate - users with medium severity alerts or multiple high-severity exfiltration activities.

Minor - users with low severity alerts or at least one high-severity exfiltration activity.

These risk levels become a live condition that DLP policies, Conditional Access policies, and retention policies can reference. The levels update dynamically as a user's behaviour changes - no admin intervention needed for individual cases.

One important nuance: risk levels are based on insights, not raw activity counts. If a user downloads 10 files from SharePoint in a single day, that counts as one insight consisting of 10 activity events. To hit Elevated, you would need three such insights at high severity - not three individual file downloads. This distinction matters significantly when you start tuning thresholds.

DLP policies can include a condition: "User's insider risk level for Adaptive Protection is..." with values of Elevated, Moderate, or Minor. This lets you create tiered enforcement.

A practical example:

• Elevated users - block external sharing on Exchange and Teams, block USB and clipboard on endpoints
• Moderate users - warn with policy tip but allow override
• Minor users - audit only, no user friction

The same content, the same action, three different outcomes depending on who is doing it. A finance analyst sharing a spreadsheet externally gets a policy tip. A finance analyst on a performance improvement plan who just downloaded 200 files gets blocked.

Important limitation: Adaptive Protection conditions in DLP only work for Exchange Online, Microsoft Teams, and Devices. SharePoint and OneDrive DLP locations are not supported. This is a significant gap - if your primary concern is SharePoint oversharing, Adaptive Protection cannot help with DLP enforcement there today.

Also worth knowing: if a user is targeted by both an Adaptive Protection DLP policy and a standard DLP policy, the most restrictive action wins. Your existing policies do not get overridden - they get supplemented.

This is where Adaptive Protection gets serious. Conditional Access policies can reference insider risk levels to control application access itself, not just data sharing.

The practical tiers most organisations adopt:

• Elevated users - block access to Office 365 apps entirely, or block access to specific sensitivity-labelled SharePoint sites (which also prevents Copilot from grounding on content in those sites)
• Moderate users - require Terms of Use acknowledgment, or force re-authentication
• Minor users - report-only mode for visibility

The power here is that Conditional Access extends Adaptive Protection beyond data to application access. An Elevated user is not just prevented from sharing - they can be locked out of the apps entirely until the situation is investigated.

This also gives you a Copilot control you cannot get any other way. If you block access to labelled SharePoint sites via Conditional Access for Elevated users, Copilot cannot ground responses on content in those sites. That is a meaningful control for organisations worried about risky users extracting sensitive information through Copilot prompts.

The newest integration, and the most underappreciated. When enabled, Adaptive Protection automatically preserves any content deleted by Elevated-risk users for 120 days across SharePoint, OneDrive, and Exchange.

Think about what this means in practice. If someone at Elevated risk starts deleting files - cleaning up evidence, wiping a OneDrive before leaving, purging emails - those deletions are silently preserved. The user sees everything disappear normally. Behind the scenes, Purview keeps it all for four months.

This is not the same as a retention policy. Retention policies apply to everyone based on rules you configure. This is targeted, automatic, and only kicks in for users whose behaviour has already triggered risk signals. You do not need to predict who will try to destroy evidence - the system identifies them and starts preserving automatically.

Admins can contact Microsoft support to restore preserved content when needed for investigation. You can also opt out of this component without disabling the rest of Adaptive Protection - there is a separate toggle.

Privacy is inconsistent. IRM pseudonymises usernames by default - analysts see identifiers like "ANON2340" instead of real names. But DLP alerts, Activity Explorer, and Conditional Access all show real names regardless of the IRM pseudonymisation setting. If your privacy team signed off on pseudonymised IRM, they need to know that enforcement actions expose real identities.

Risk levels are not alert severities. Alert severity (Low/Medium/High) is about the individual alert. Risk levels (Minor/Moderate/Elevated) are about the user's aggregate risk posture. A user can have a Low severity alert but still be at Elevated risk if they have multiple insights. These are distinct concepts that are easy to conflate.

Risk levels expire automatically. By default, a risk level resets after 7 days (configurable 5-30). If a user qualifies again during that window, the timer extends. Levels also reset when alerts are dismissed or cases are resolved. This is good for false positives but means a truly risky user whose case gets closed prematurely drops back to unrestricted access.

Up to 36 hours for risk levels to take effect after the initial setup completes. And up to 6 hours for risk level assignments to fully clear when you turn Adaptive Protection off. Plan accordingly if you are testing.

Permissions are fragmented. You need IRM role groups for risk levels, DLP role groups for DLP policies, and Entra role groups for Conditional Access. No single role covers everything. Plan the RBAC before you start.

Adaptive Protection is not a nice-to-have feature for mature organisations. It is a fundamental shift in how data protection should work.

Static policies were designed for a world where you could not tell the difference between a normal user and a risky one. Now you can. IRM builds a behavioural baseline for every user and flags deviations. Adaptive Protection takes those signals and makes your enforcement smart enough to act on them.

The result: most users never notice your DLP policies exist. The handful who trigger risk signals get progressively tighter controls - from policy tips, to blocks with override, to application lockout, to silent evidence preservation. All automatic. All dynamic. All without an admin manually adjusting policies for individual users.

If you already have IRM deployed, enabling Adaptive Protection is the highest-impact next step. If you do not have IRM yet, this is the reason to prioritise it - not the alerts and cases, but the dynamic enforcement layer it unlocks across DLP, Conditional Access, and Data Lifecycle Management.