Purview Compliance Portal Retired: What Moved

The Portal Used to Be Three Things

Before April 2022, you had Azure Purview (data governance), the Microsoft 365 Compliance Center (compliance.microsoft.com), and the old Security & Compliance Center (protection.office.com). Microsoft collapsed these into one brand: Microsoft Purview. The compliance portal at compliance.microsoft.com then absorbed the compliance workloads.

That portal is now retired too. Everything moved into the unified Microsoft Purview portal at purview.microsoft.com, which also hosts data governance. Old bookmarks redirect. A few things moved on the way: Classification is now Classifiers inside each solution, Explorers and Policies sit in each solution's left nav, roles and scopes live under Settings, and Content Search is now part of eDiscovery. Privacy Risk Management went to the separate Microsoft Priva portal. The classic eDiscovery experiences were retired on August 31, 2025.

People still search for "the Purview compliance portal", and that is fine. It is the same workloads under a new front door.

When a client says "we need to get Purview set up," the first question we ask is: which Purview? The answer determines your licensing conversation, your engineering surface, and which team owns the config. This note covers the compliance workloads specifically, because that is where most of the operational complexity lands.

What the Portal Actually Contains

The left nav in the Purview portal is wide. Here is what we spend real time in versus what exists mostly as checkbox compliance:

Active workloads. Data Loss Prevention (DLP), Information Protection (sensitivity labels via MIP), Communication Compliance, Insider Risk Management, Data Lifecycle Management (retention policies and labels), Audit, and eDiscovery. These are live, policy-enforcing surfaces that affect mail flow, Teams messages, SharePoint content, and endpoint file operations.

Compliance Manager. A scored assessment dashboard against frameworks (NIST 800-53, ISO 27001, CMMC, etc.). Useful for audit prep. The score is calculated from your M365 tenant config, not from any external scan. Clients over-trust the score because Microsoft controls what "improvement actions" it counts.

eDiscovery, including what used to be Content Search. Premium eDiscovery features require E5 or an add-on. Search with KQL is available lower down the stack and is the fastest way to confirm data residency or scope a breach before escalating to legal hold.

The portal does not surface everything. Cross-tenant config, custom sensitive information type training at scale, and anything touching the Graph API compliance endpoints all need PowerShell or direct API calls.

Communication Compliance and the Classifier Problem

Communication Compliance scans Teams, Exchange, and Viva Engage messages for policy violations: harassment, regulatory disclosures, code-of-conduct breaches. Microsoft ships a library of built-in trainable classifiers. The preview release of additional classifiers (healthcare regulatory language, source code exfiltration, and several others) started reaching tenants in mid-2025.

The catch: classifier quality is uneven. We have seen the "Threat" classifier fire on routine sports chat and miss explicit social-engineering attempts because the phrasing was polite. Before enabling any Communication Compliance policy in enforce mode, run it in simulation for at least 30 days. Look at the alert volume. If you are getting more than 3-5% false-positive rate on a trained classifier, retrain or tighten the policy scope to specific user groups.

Retraining a trainable classifier requires the Compliance Administrator role plus either E5 or the Compliance add-on SKU. You feed it sample content via the Content Explorer surface. Expect 24-48 hours per training iteration. There is no API shortcut here; it is all UI-driven, which is slow when you are iterating on a tight deployment timeline.

One pattern that works: scope Communication Compliance policies to high-risk groups (executives, finance, M&A teams) first, validate recall and precision there, then expand. Blanket tenant-wide policies on noisy classifiers generate alert fatigue fast enough to kill analyst trust in the whole pipeline.

Getting Purview Signals into Sentinel

Raw audit events are searchable inside the Purview portal, but for any real detection program you want them in Sentinel. There are three routes, and they land in different tables:

The Microsoft 365 connector brings Exchange, SharePoint and Teams audit events into OfficeActivity. Those are free to ingest. DLP and sensitivity label events do not come this way.
The Defender XDR connector brings Purview DLP and Insider Risk alerts in as incidents, with the alerts in SecurityAlert. Alerts and incidents are also free.
The CloudAppEvents table, enabled through the same Defender XDR connector, carries the wider Office 365 audit log, including the user activity behind a DLP alert. It is billable, so size it before you switch it on.

Audit (Standard) retains 180 days. Audit (Premium) keeps Entra ID, Exchange, OneDrive and SharePoint records for one year by default. Other record types stay at 180 days unless a retention policy extends them. 10-year retention needs a separate per-user add-on licence. If your client is on E3, they get the 180-day window. Budget conversations need to happen before you architect a 12-month detection lookback.

A starting query for DLP alert volume, once the Defender XDR connector is on:

SecurityAlert
| where TimeGenerated > ago(7d)
| where ProductName has "Data Loss Prevention"
| summarize
    Alerts = count(),
    Rules  = make_set(AlertName, 20)
    by bin(TimeGenerated, 1h)
| order by Alerts desc

This gives you hourly DLP alert volume and which policies fired. A sudden spike across many users is one of the faster signals for a compromised account doing bulk exfiltration. Turn it into a scheduled analytics rule with a threshold you tune after 2 to 3 weeks of baseline data. To see what a user actually did around an alert, Microsoft's DLP investigation guide shows how to join the alert to CloudAppEvents by time window.

Sensitivity label downgrades, where a user removes or demotes a label, show up in Activity explorer and in the audit log. Joining them against your HR system's leaver list is worth the effort. Label stripping before a departure is a classic insider risk signal.

DLP Policy Simulation Mode Before You Pull the Trigger

Every DLP policy in Purview supports a simulation (test) mode where matches are logged but no action is taken. Use it. We have seen production DLP enforcements block legitimate business processes on day one because someone skipped simulation.

The workflow we follow:

# Connect to Security & Compliance PowerShell
Connect-IPPSSession -UserPrincipalName [email protected]

# Create the policy in simulation mode first
New-DlpCompliancePolicy `
  -Name "Financial-Data-Exfil-Watch" `
  -Mode TestWithNotifications `
  -ExchangeLocation All `
  -SharePointLocation All `
  -OneDriveLocation All

# Add a rule targeting credit card + high volume
New-DlpComplianceRule `
  -Name "CCN-Bulk-Send" `
  -Policy "Financial-Data-Exfil-Watch" `
  -ContentContainsSensitiveInformation @{
      Name = "Credit Card Number";
      minCount = "5";
      confidenceLevel = "High"
  } `
  -ReportSeverityLevel High `
  -GenerateIncidentReport SiteAdmin `
  -IncidentReportContent ("Title","Severity","RulesMatched","Detections")

Run this for 2-4 weeks. Pull the DLP reports from the portal (Reports > DLP policy matches) or export the matches from Activity explorer. Tune the minCount threshold based on what you see. Flip to Enforce mode only after you have reviewed at least one full business cycle of match data.

Licensing Is a Hard Wall, Not a Soft Warning

The Purview portal will show you features you cannot actually use. Insider Risk Management requires E5 or the Insider Risk add-on. eDiscovery Premium requires E5. Audit (Standard) keeps logs for 180 days. Longer retention needs Audit (Premium), which comes with E5 or an add-on. Communication Compliance requires E5 Compliance or the standalone SKU.

When we audit a new client tenant, we run a license gap check first:

Connect-MgGraph -Scopes "Organization.Read.All","LicenseAssignment.ReadWrite.All"

$skus = Get-MgSubscribedSku | Select-Object SkuPartNumber, ConsumedUnits, PrepaidUnits
$skus | Where-Object {
    $_.SkuPartNumber -match "COMPLIANCE|EMS|M365E5|INFORMATION_PROTECTION"
} | Format-Table -AutoSize

Map what you find against the Microsoft 365 licensing comparison matrix. Do this before any architecture conversation. Clients building Purview roadmaps on E3 assumptions then discovering they need per-user E5 compliance add-ons is a common and avoidable budget shock.

One thing worth knowing: the Compliance Manager score counts some controls as satisfied by features you have not licensed, as long as the feature exists in your tenant SKU family. The score does not verify that you have actually configured the control. Treat it as a gap list, not a readiness certificate.

When to Call Us

If you are standing up a Purview compliance program and need the detection pipeline, DLP tuning, Communication Compliance rollout, or the Sentinel integration done right, see what we cover at /services/detection or reach out at /contact.

Microsoft Purview Compliance Portal: What Actually Works in Production