What Microsoft Purview Actually Is, and What It Is Not

Microsoft Purview is one brand name on top of two separate product families that were built by different engineering organizations, acquired at different times, and still require separate configurations. When a customer asks "what is Microsoft Purview," they usually mean one of those families and do not realize the other exists. Getting that wrong at the beginning of an engagement means building a Data Map nobody asked for, or skipping the DLP policies the legal team actually needed. We have walked into both situations.

Two Products, One Confusing Name

The first family is Microsoft Purview Data Governance, previously called Azure Purview, previously called Azure Data Catalog. It lives in the Azure portal. Its job is to scan your data sources, classify what is in them, build a lineage graph, and surface a searchable catalog of data assets across your estate. Think of it as inventory for your data: what exists, where it lives, who owns it, and how it flows between systems.

The second family is Microsoft Purview compliance solutions, previously the Microsoft 365 compliance center. It lives at compliance.microsoft.com and is licensed through Microsoft 365 E3/E5 or add-on SKUs. Its job is information protection: sensitivity labels, Data Loss Prevention (DLP), eDiscovery, Insider Risk Management, Compliance Manager, and Communication Compliance.

These two families share a Purview portal at purview.microsoft.com as of mid-2023, but the underlying services, APIs, and licensing models remain separate. A Purview governance account in Azure does nothing for your DLP policies in Exchange, and an M365 E5 Compliance license does not give you the ability to scan an AWS S3 bucket through the Data Map.

The Governance Side: Scanning and Cataloging Your Estate

The Azure-native side provisions through a Purview account resource in your subscription. Once you have one, you register sources, configure scanning credentials, and let the managed runtime (either the shared Azure IR or a self-hosted integration runtime for on-premises or private network sources) run classification scans.

We typically start a new Purview account with the Azure CLI:

# Create a resource group and Purview account
az group create \
  --name rg-purview-prod \
  --location eastus2

az purview account create \
  --name kmt-purview-prod \
  --resource-group rg-purview-prod \
  --location eastus2 \
  --sku-name Standard \
  --public-network-access Disabled

# Assign the current principal as a data curator
PURVIEW_ID=$(az purview account show \
  --name kmt-purview-prod \
  --resource-group rg-purview-prod \
  --query id -o tsv)

az role assignment create \
  --role "Purview Data Curator" \
  --assignee "$(az ad signed-in-user show --query id -o tsv)" \
  --scope "$PURVIEW_ID"

After that, sources get registered through the Purview portal or via REST. The data plane API at https://<account>.purview.azure.com handles collections, assets, lineage, and classification rules. The scan results populate an Apache Atlas-based metadata store, which you query through the catalog.

For large enterprises, the interesting work is in custom classification rules (regex or dictionary-based patterns for industry-specific identifiers like VINs, account numbers, or healthcare codes), collection hierarchies that mirror your org structure, and wiring Atlas lineage into your pipeline metadata so the graph reflects actual data movement rather than just point-in-time scans.

The Compliance Side: Labels, DLP, and eDiscovery

The M365-family side is configured through compliance.microsoft.com and PowerShell. The core object is a sensitivity label: a named, ordered classification (Confidential, Highly Confidential, etc.) that triggers encryption, watermarking, header/footer injection, or DLP policy enforcement wherever content lands.

Labels propagate across Teams, SharePoint, OneDrive, Exchange, and, with the Purview Information Protection client, Office files on Windows endpoints. The compliance side also integrates with the governance side through auto-labeling: you can define label conditions in compliance.microsoft.com that apply based on sensitive information types, and those same SITs can be referenced in governance scan rules.

DLP policies sit on top of labels. A policy watches for labeled or pattern-matched content crossing specific channels (email, Teams chat, SharePoint uploads, endpoint clipboard events) and can block, audit, or require business justification depending on the rule severity.

Where Purview Feeds Sentinel

One of the more useful integration points we build at KeMeT is shipping Purview audit logs into Microsoft Sentinel. The compliance side emits audit events for label changes, DLP rule hits, eDiscovery holds, and Insider Risk alerts. These land in the PurviewDataSensitivityLogs and MicrosoftPurviewInformationProtection tables when you enable the Purview connector in Sentinel.

A KQL query we run in almost every engagement to surface DLP policy matches across endpoints:

MicrosoftPurviewInformationProtection
| where TimeGenerated > ago(7d)
| where Activity == "DLPRuleMatch"
| extend LabelName = tostring(parse_json(PolicyDetails)[0].Rules[0].RuleConditionsMatched[0].SensitiveInfoTypeName)
| extend UserPrincipalName = tostring(UserId)
| extend SourceLocation = tostring(ObjectId)
| summarize
    MatchCount = count(),
    UniqueUsers = dcount(UserPrincipalName),
    UniqueFiles = dcount(SourceLocation)
    by LabelName, PolicyName, bin(TimeGenerated, 1d)
| order by MatchCount desc

This surfaces which policies are firing most, which labels are involved, and whether match volume is concentrated on a few users (potential insider risk signal) or spread broadly (potential false-positive in the policy definition). From Sentinel you can build analytics rules that page your SOC when a single user hits more than N DLP blocks in a 24-hour window.

Licensing: Where Budgets Break

Governance is priced per capacity unit per hour in Azure. A single-region standard account with light scan volume runs around $1.50 to $3.00 per hour for the compute portion, plus storage costs for the metadata. Heavy classification scans across petabyte-scale estates can cost more than the data warehouse you are scanning.

The compliance side is mostly locked to M365 licensing tiers. E3 gives you basic sensitivity labels and DLP. E5 Compliance (or the add-on) unlocks Insider Risk, Communication Compliance, Advanced eDiscovery, and Compliance Manager scores. Per-user pricing as of this writing is in the $10-12/month range for the E5 Compliance add-on, but Microsoft's SKU structure changes frequently, so confirm against the current product terms.

The licensing gap we see most often: a customer has M365 E3, enables sensitivity labels, and then discovers the endpoint DLP policies they need to block exfiltration to USB or personal cloud storage require E5 Compliance. That is a significant per-seat jump across a large tenant. We scope this before any labeling work begins.

What Purview Does Not Do

Purview is not a SIEM. It generates signal; it does not correlate it. Without Sentinel or another aggregator, audit events stay in the compliance portal and require manual investigation.

It is not a database activity monitor in the traditional sense. The governance scan tells you what data exists in a database, not who queried it at runtime. For that, you need Azure SQL Auditing, Defender for SQL, or a purpose-built DAM solution feeding Sentinel.

It is also not a data quality platform. Classification and lineage tell you what your data is and where it goes. They say nothing about whether the values in a column are accurate, complete, or consistent. We have had customers expect Purview to surface data quality failures. It will not, at least not without significant custom classification logic and a separate quality framework wired into the catalog.

When to Call Us

If you are scoping a Purview deployment, mapping out licensing gaps before a compliance audit, or building the Sentinel integration to turn Purview signals into SOC-actionable alerts, reach out to the team at KeMeT Tech. For the broader detection and compliance architecture this fits into, see our detection engineering practice.