Microsoft Purview Adaptive Protection
Dynamic Data Loss Prevention and Conditional Access enforcement driven by Insider Risk Management risk levels
Difficulty
Advanced
Environment
Microsoft 365 tenant (Microsoft Purview compliance portal)
Deployment
Home Lab
Est. Implementation
3-5 hours
Executive Summary
This project documents the configuration and verification of Microsoft Purview Adaptive Protection, which connects Insider Risk Management risk levels to Data Loss Prevention and Conditional Access enforcement, allowing those policies to automatically tighten controls against specific high-risk users without manual scope changes.
The lab began from a real, observed outage state — Adaptive Protection disabled because its source insider risk policy had been deleted — and walks through diagnosis, recovery, risk-level configuration, and PowerShell-based health verification.
Business Problem
Static DLP and Conditional Access policies apply the same controls to every user regardless of their actual behavioral risk, meaning either all users are subject to strict friction-heavy controls, or high-risk users are not treated any differently from low-risk ones. Organizations need enforcement that automatically escalates for specific users identified as elevated risk, without administrators manually re-scoping policies.
Without Adaptive Protection, insider risk signals computed by Insider Risk Management have no automated path into enforcement — an elevated-risk user continues operating under the same DLP and Conditional Access controls as every other user until a human intervenes.
Business Risks
- Adaptive Protection silently disabled if its source insider risk policy is deleted, with no automatic remediation
- Elevated-risk users retaining full access under Conditional Access until manually restricted
- DLP policies not tightening automatically for users already flagged as high risk
- Report-only Conditional Access policies providing no real enforcement if never promoted to enforced
Compliance Concerns
- Zero Trust adaptive access control
- Insider threat risk-based enforcement
- Regulatory data protection obligations
Solution Overview
Identified and diagnosed the initial Adaptive Protection outage state, caused by the deletion of its source Insider Risk Management policy.
Re-enabled Adaptive Protection at the tenant level from the Adaptive Protection settings page.
Configured Elevated, Moderate, and Minor insider risk level thresholds sourced from the Data Leaks Insider Risk Policy.
Reviewed the Conditional Access policy (Block access to Office Apps for users with Insider Risk, Report-only, Elevated) that consumes Adaptive Protection risk levels.
Reviewed the two Data Loss Prevention policies (Teams/Exchange and Endpoint) that consume Adaptive Protection risk levels.
Verified the Adaptive Protection policy and all related Insider Risk Management policies using Security & Compliance PowerShell.
Architecture
Architecture diagram placeholder
Technology Stack
Microsoft Purview Adaptive Protection
Connects computed insider risk levels to downstream DLP and Conditional Access enforcement
Microsoft Purview Insider Risk Management
Source of Elevated, Moderate, and Minor risk level classifications
Microsoft Purview Data Loss Prevention
Teams/Exchange and Endpoint DLP policies that tighten automatically for elevated-risk users
Microsoft Entra Conditional Access
Report-only policy blocking Office Apps access for users flagged at Elevated insider risk
Security & Compliance PowerShell
Used to verify policy health, mode, and enabled state for Adaptive Protection and Insider Risk Management
Lab Environment
- Source Insider Risk Policy
- Data Leaks Insider Risk Policy
- Adaptive Protection Policy
- Adaptive Protection policy for Insider Risk Management (system-generated)
- Conditional Access Policy
- Block access to Office Apps for users with Insider Risk (Preview) — Report-only, Elevated
- DLP Policies
- Adaptive Protection policy for Teams and Exchange DLP; Adaptive Protection policy for Endpoint DLP
Implementation
A phased, expandable walkthrough. Screenshots and evidence can be attached to each phase.
Identified that Adaptive Protection was disabled because its source insider risk policy had been deleted, then re-enabled the feature at the tenant level.
- Review the Adaptive Protection dashboard (initial disabled state)
- Diagnose the outage: source insider risk policy previously used for Adaptive Protection had been deleted
- Enable Adaptive Protection in settings
Screenshots for this phase can be added here.
PowerShell
Illustrative example snippets — copy or download each script. Production values are placeholders.
Adaptive Protection and Insider Risk Policy Verification
# Confirm the Adaptive Protection policy is enabled and healthy
Get-InsiderRiskPolicy | Where-Object {$_.Name -like "*Adaptive*"} | fl Name,Enabled,PolicyHealth
# Confirm the mode, state, and enabled status of every Insider Risk Management policy
Get-InsiderRiskPolicy | fl Name,Mode,State,EnabledConfiguration Screenshots
Click any tile to open the lightbox. Real screenshots will replace these placeholders.
Phase 1
Phase 2
Phase 3
Phase 4
Validation
Adaptive Protection outage diagnosed
Confirmed via dashboard — disabled state traced to deleted source insider risk policy — Pass
Adaptive Protection re-enabled
Confirmed via settings page — Pass
Insider risk levels configured
Elevated, Moderate, Minor thresholds confirmed — Pass
Conditional Access policy reviewed
Confirmed Report-only, Elevated scope — Pass
DLP policies reviewed
Two policies (Teams/Exchange, Endpoint) confirmed referencing insider risk — Pass
Adaptive Protection policy health verified via PowerShell
Enabled: True, HealthStatus: Healthy — Pass
Insider Risk Management policies verified via PowerShell
Mode: Enable, Enabled: True for all related policies — Pass
Challenges
Real outage from a deleted source policy
Adaptive Protection was found disabled at the start of the lab because the insider risk policy it originally sourced risk levels from had been deleted — documented as the genuine starting state rather than a simulated failure.
Report-only Conditional Access provides no real enforcement
The Conditional Access policy consuming insider risk levels remains in Report-only mode, meaning it currently only logs matching sign-ins rather than actually blocking access.
Lessons Learned
- Adaptive Protection has a hard dependency on its source Insider Risk Management policy — deleting that policy silently disables downstream enforcement rather than failing loudly.
- PowerShell verification can reveal system-generated policies (such as IRM_Tenant_Setting_...) that are not otherwise surfaced in the Purview portal UI.
- Deploying new Conditional Access policies in Report-only mode first, as observed in this lab, is a safer rollout pattern than enforcing immediately.
- Turning off Adaptive Protection can take up to 6 hours to fully stop assigning and resetting risk levels, which has real operational implications for lab teardown or emergency rollback.
Business Impact
Healthy
Policy Health
3-Tier (Elevated/Moderate/Minor)
Risk Levels
DLP + Conditional Access
Enforcement Surfaces
PowerShell-Validated
Verification
Skills Demonstrated
Related Certifications
Certifications this project maps to are highlighted.
Related Blog Articles
Placeholder cards — future TechCertGuide integration.
GitHub Repository
Microsoft-Adaptive-Protection
PublicConfiguration and verification of Microsoft Purview Adaptive Protection linking Insider Risk Management to DLP and Conditional Access enforcement
Download Center
Project Case Study
PDF · Available soon
Architecture Diagram
PDF · Available soon
PowerShell Scripts
ZIP · Available soon
Technical Documentation
PDF · Available soon