In many of the Microsoft 365 environments I support, the pressure to take insider risk seriously is very real. Most organizations already run traditional DLP and access controls, but these are usually static and treat every user the same, no matter how they actually behave. Adaptive Protection in Microsoft Purview changes that, because controls can now respond to a user's actual risk profile. Moving from blanket rules to targeted, automated responses makes a big difference, especially for organizations that have struggled to tune their DLP policies so they protect data without getting in everyone's way.

Adaptive Protection assigns every user a dynamic risk level

Adaptive Protection sits on top of the Insider Risk Management features in Microsoft Purview. The engine keeps evaluating users based on policy activity, anomaly signals and, if you choose, HR data (to catch leavers or role changes, for example). Every user ends up with a dynamic risk level of Minor, Moderate or Elevated. That level is more than a label. It directly determines how strict DLP, Conditional Access and monitoring are for that person. If someone's risk rises to "Elevated", DLP can immediately restrict their ability to download, share or move sensitive data, and Conditional Access can even block them from critical apps.

The Purview setup needs E5 licensing and only a few clicks

You need Microsoft 365 E5 or E5 Compliance licensing, plus configured Insider Risk Management policies. HR connectors are optional, but they add useful context. The setup itself is quick. In the Microsoft Purview portal, go to Insider Risk Management and open the Adaptive Protection blade, where you can switch it on in a couple of clicks. Usernames are pseudonymised by default, which German works councils appreciate a lot, since only privileged roles can ever see real names. In several projects this made the first stakeholder conversations much easier.

The diagram below shows how Adaptive Protection connects risk scoring, DLP and Conditional Access:

flowchart TD
  User["User activity"] --> IRM["Insider Risk Policy evaluates risk"]
  IRM --> RiskLevel["Risk level (Minor/Moderate/Elevated)"]
  RiskLevel --> DLP["DLP policy adapts response"]
  RiskLevel --> CA["Conditional Access checks risk"]
  DLP --> Block["Stricter actions (block, audit)"]
  CA --> Access["Allow/block access"]

Figure: With Adaptive Protection, DLP and Conditional Access respond to each user's current risk level.

DLP policies respond differently depending on the risk level

DLP (Data Loss Prevention) policies are where you notice the change most in day-to-day operations. You can now target users directly by their Insider Risk level, for example by applying tighter restrictions or blocking actions for anyone at "Elevated Risk". This works across Exchange, SharePoint, OneDrive and Teams, as long as DLP covers them. For the practical details, the official documentation is a good place to start: Learn about DLP.

Practical tip: If you already have DLP rules in place, there's no need to rebuild them. Add one more rule with the condition “Insider Risk Level = Elevated” for stricter enforcement on those users, and leave your baseline protection in place for everyone else.

All usernames in reports and dashboards are pseudonymised by default. Only users with privileged roles can reveal real identities, and that alone has made privacy discussions, particularly with works councils, much less painful. Microsoft covers these controls in detail here: Adaptive Protection docs.

Conditional Access can now use insider risk as a condition

One of the more important updates is that Conditional Access (CA) now supports the user's Insider Risk level. When you configure a CA policy, you'll see a new "Users with Insider Risk" selector as an additional user assignment condition. With it you can block access, require stronger authentication or restrict resources such as Teams or SharePoint only for users that Insider Risk Management has flagged. According to Microsoft's documentation (Conditional Access insider risk condition), the CA condition always uses the current risk level from Insider Risk Management, so the controls adjust in near real time.

If you're still working on your first Conditional Access policies, my post Conditional Access in Microsoft Entra ID: The First Policies Every Tenant Needs has more tips.

I see Adaptive Protection as adaptive rather than merely reactive

For me, Adaptive Protection is a step that was overdue, because it stops treating every user as the same risk. The idea that everyone gets identical controls no longer fits real environments, where teams change quickly and business-critical data lives everywhere. Once your E5 licensing is in order, the technical setup isn't the hard part anymore. The real effort goes into talking to stakeholders. Involve the works council early, document the pseudonymisation clearly and keep access to real identities tightly restricted. If you do that, insider risk stops being a static afterthought and becomes something you can actually manage as it changes. That's what I value most here, because security finally adapts instead of just being switched on or off.