Learn › Microsoft Purview › 5 · DSPM & AI security

Data governance: the Data Map and catalog

This is Purview's other half: cataloguing the wider data estate — databases, lakes, warehouses, SaaS — not just M365 content. The Data Map scans and classifies sources into a searchable catalog with lineage. It shares the classification vocabulary with the compliance half but is a separate plane with separate tooling.

The other half, briefly

Everything else in this curriculum governs Microsoft 365 content — mail, files, chats. Data governance governs the enterprise data estate: SQL and other databases, data lakes, warehouses, Azure/AWS/GCP sources, Power BI and integrated SaaS. Different audience (data teams, not M365 admins), different plane, but under the same Purview brand — and that shared brand is exactly why the two get conflated.

The Data Map and the catalog

  • The Data Map is the metadata graph underneath — a scanned, classified inventory of registered sources. Scans connect to a source, read its schema and (with the shared classification engine) tag columns/assets with sensitive information types.
  • The unified catalog is the human surface over the map: search and browse assets, see classifications, owners, glossary terms, and lineage — how data flows from source through pipelines to reports (the "where did this figure come from / what breaks if I change this table" answer).
  • Data quality and governance domains layer business ownership and quality rules on top of the technical inventory.

Where the halves meet — and don't

They share the classification vocabulary (SITs/classifiers), so "credit card number" means the same thing in a SQL column and a SharePoint file — that's the genuine link. But they are separate control planes: a sensitivity label or DLP policy on the M365 side does not automatically govern a scanned database column, and cataloguing a data lake does not apply M365 retention to it. Expecting one half's policies to reach into the other is the core misconception.

The tooling boundary (the PowerShell failure mode)

This half is not managed through Connect-IPPSSession. The data map/catalog is administered via the Purview portal, its REST/Atlas APIs, and the Az.Purview PowerShell module (account-level, e.g. Get-AzPurviewAccount) — a different auth model and a different permission plane from the compliance solutions. Any scanner or automation must treat these as two distinct surfaces; credentials and RBAC for one do not grant the other. Stating that boundary plainly is the honest coverage line.

What to watch (proofs)

  • Source coverage: which sources are registered and scanned, and scan freshness (Purview data map / catalog) — unscanned sources are ungoverned data, and stale scans are stale classification.
  • Classification reach: sensitive-data classifications surfaced on scanned assets — the enterprise-estate equivalent of the M365 coverage metric.
  • Lineage completeness: assets with lineage vs without — gaps are where impact analysis (and audit) breaks down.
  • The boundary, stated: account-level enumeration via Get-AzPurviewAccount (Az module) vs the IPPSSession compliance cmdlets elsewhere in this curriculum — proof the two planes are governed separately, coverage claimed per plane.

PowerShell for this concept

  • Get-AzPurviewAccount
  • Connect-IPPSSession For more information, see About the Exchange Online PowerShell module. Use the...

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.