Microsoft Purview: Data Catalog, DLP, Compliance, and Classification Setup
Why This Is Happening
I've sat across from IT administrators who have stared at the Microsoft Purview portal for the first time and genuinely felt lost. And I get it , the product is enormous. Microsoft Purview brings together data governance, data security, and data compliance into one unified platform, and that's both its strength and the source of most setup headaches. You're not dealing with one product. You're dealing with a whole ecosystem: the Unified Catalog, the Data Map, Information Protection, Data Loss Prevention, Compliance Manager, Insider Risk Management, and more , all under one roof, all with their own permissions model.
The single biggest reason Microsoft Purview setup problems happen? Permissions. The Purview portal uses its own role assignments that are separate from Azure RBAC and separate from Microsoft 365 admin roles. Someone can be a Global Administrator in Entra ID and still hit a wall the moment they try to scan a data source or publish a sensitivity label. It's genuinely counterintuitive, and Microsoft's error messages don't help. You'll see something like "You don't have permission to perform this action" or HTTP 403 Forbidden with zero detail about which role you're actually missing.
Beyond permissions, Microsoft Purview data classification setup trips people up because labels, policies, and auto-labeling rules live in different places and have to be published before they do anything at all. I've seen engineers spend two hours troubleshooting why their sensitivity labels aren't appearing in Office apps, only to discover the label policy was created but never published to users. The portal doesn't warn you loudly enough about that distinction.
On the data governance side, Microsoft Purview Data Map and Unified Catalog setup failures usually trace back to one of three things: the managed identity for your Purview account doesn't have the right role on the source subscription, the firewall on your storage account is blocking the scanner, or you registered a data source in the wrong collection and the scan credentials can't reach it.
For Microsoft Purview DLP policy configuration, the most common complaint is "my policy is on but it's not blocking anything." That almost always comes down to policy mode, new DLP policies default to simulation mode, not enforcement. Admins expect blocking behavior immediately and don't realize the policy is quietly logging violations without acting on them.
I know this feels like a lot to unpack, especially when your deadline was yesterday. This guide walks you through every major setup step and the fixes for the errors you're most likely to hit. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If you've just set up Microsoft Purview and nothing seems to be working, sensitivity labels aren't showing up, DLP policies aren't triggering, scans are failing, there's one thing to check before you go any further: role assignments inside the Purview portal itself.
Go to the Microsoft Purview portal at purview.microsoft.com. In the left navigation, scroll down and click Settings, then select Roles and scopes. Look at the Role groups tab. You need to confirm that your account (or the account experiencing the issue) is a member of the correct role group for the task at hand.
Here's a fast reference for what breaks without which role:
- Sensitivity labels not visible or publishable: You need to be in the Information Protection or Information Protection Admins role group.
- DLP policies can't be created or edited: You need DLP Compliance Management or the Compliance Administrator role group.
- Data Map scans failing with access errors: The Purview managed identity needs Storage Blob Data Reader on the Azure storage account, this is assigned in the Azure portal, not Purview.
- Compliance Manager assessments not loading: You need the Compliance Manager Assessor or Compliance Manager Administrator role.
- Unified Catalog items not appearing: Check that you have Data Reader or Data Curator on the relevant collection in the Data Map.
Once you've confirmed role assignments, give it up to 30 minutes for changes to propagate, especially across tenants with Conditional Access policies in play. Sign out of the portal completely, clear your browser cache, and sign back in. That alone resolves roughly 40% of the "nothing is working" reports I see.
If you're on a domain-joined machine and the portal is loading blank pages or throwing JavaScript errors, try opening it in a private/InPrivate browser window. Browser extensions, particularly corporate proxy extensions or older versions of the Azure AD Browser Extension, can interfere with Purview's portal rendering.
Before touching any Microsoft Purview data governance setup, you need to confirm three things: the right licenses are assigned, the right roles are granted, and the portal is actually accessible. Skipping this step is how people end up chasing phantom bugs for hours.
Licensing check: Most Microsoft Purview features require Microsoft 365 E3 at a minimum. Information Protection auto-labeling, Insider Risk Management, and Advanced eDiscovery require E5 or the Microsoft Purview compliance add-on. In the Microsoft 365 admin center, go to Billing > Licenses and confirm the user has an active license assigned.
Role assignment: Navigate to purview.microsoft.com > Settings > Roles and scopes > Role groups. Click Compliance Administrator and then Edit. Add your account under the Members tab. For data governance tasks specifically, you'll also need to set up collection-level roles in the Data Map, covered in Step 2.
Portal access test: Open a new InPrivate browser window and navigate to purview.microsoft.com. If you see a blank white screen or get redirected to a generic Microsoft sign-in loop, the issue is likely Conditional Access blocking access to the Purview application. Check your Entra ID Conditional Access policies under Protection > Conditional Access > Policies and look for any policy that targets "All cloud apps" and might be blocking the Microsoft Purview Compliance Portal app ID (80ccca67-54bd-44ab-8625-4b79c4dc7775).
If everything loads correctly, you should see the Purview portal home page with tiles for Data Catalog, Information Protection, Data Loss Prevention, and Compliance Manager, those four being the most commonly configured areas. Once you can see all of them without errors, proceed to Step 2.
The Microsoft Purview Data Map is the backbone of Purview's data governance capabilities, it's what the Unified Catalog draws from, and it's where your scan rules, classification rules, and data source registrations live. Getting this right early saves enormous pain later.
In the Purview portal, go to Data Map in the left navigation. Select Collections. Your root collection is created automatically when the Purview account is provisioned. You'll want to create a logical hierarchy, for example, a top-level collection per business unit or per cloud environment (Azure, AWS, on-premises).
To register a data source, click Data Map > Data sources > Register, then choose your source type (Azure Data Lake Storage Gen2, Azure SQL Database, Azure Blob Storage, etc.). The most common registration error here is:
Error: The managed identity does not have sufficient privileges to scan the data source.Fix this by going to the Azure portal, navigating to your storage account or SQL server, and assigning the Purview managed identity the Storage Blob Data Reader role (for ADLS/Blob) or adding it as a db_datareader in the SQL database. The Purview managed identity name matches your Purview account name exactly, find it under Settings > Account inside Purview.
If your storage account has a firewall enabled, you also need to add the Purview account's managed identity to the Resource instances exceptions, or temporarily allow trusted Microsoft services. After fixing permissions, go back to Data sources, find your registered source, and click New scan. Run a test scan first, it validates connectivity without ingesting metadata. A green checkmark means you're ready to run the full scan and start populating the Unified Catalog.
Microsoft Purview sensitivity labels are the foundation of your data classification setup. They drive encryption, watermarking, DLP policy conditions, and auto-labeling across Microsoft 365 apps, Azure, and third-party platforms. But they do nothing, literally nothing, until they're published to users via a label policy.
Go to purview.microsoft.com > Information Protection > Labels. Click Create a label. Give it a name and display name, note that the display name is what users see in Office apps, so make it human-readable (e.g., "Confidential – Internal Only" rather than "CONF_INT_01"). Work through the wizard:
- Scope: Select Items (covers files and emails) and Groups & sites if you want to apply protection at the SharePoint site level.
- Protection settings for labeled items: If you want encryption, select Apply or remove encryption. Assign permissions, set specific users/groups or use the "any authenticated user" option for internal-only labels.
- Auto-labeling: Available only with E5 or the compliance add-on. You can configure it to match credit card numbers, passport numbers, or any of the 300+ built-in sensitive information types.
After creating the label, go to Label policies > Publish label. Select your new label, choose which users or groups should see it, and configure the default label behavior. Hit publish. This is the step most people forget.
After publishing, allow up to 24 hours for labels to propagate to Office clients. To force a faster sync on a specific machine, run this in an elevated PowerShell session:
Connect-IPPSSession
Get-Label | Select-Object DisplayName, Guid, IsActiveIf your label appears in that output but not in Word or Outlook, the issue is typically the AIP unified labeling client not being updated. Check the client version at Help & Feedback > Version Info inside any Office app's sensitivity label menu.
Microsoft Purview DLP policy configuration is where I see the most "it's not working" tickets, and almost every one of them comes down to the same two issues: the policy is in simulation mode, or the policy scope doesn't include the right workloads.
Go to purview.microsoft.com > Data Loss Prevention > Policies > Create policy. You can start from a template (Financial, Medical, Privacy, etc.) or build from scratch. The template approach is faster and covers the most common regulated data types out of the box, I recommend it unless you have very specific requirements.
The critical settings are on the Policy mode page near the end of the wizard:
- Simulation mode: Logs violations, generates alerts, does NOT block or notify users. This is the default for new policies.
- Turn it on right away: Activates enforcement. Users see policy tips. Blocking rules actually block.
Set the mode to "Turn it on right away" unless you genuinely want a test run first. If you ran a simulation and want to review what it caught before enforcing, go to DLP > Activity Explorer, filter by your policy name and look for DLP rule matched events.
For workload coverage, make sure you've selected all relevant locations: Exchange email, SharePoint sites, OneDrive accounts, Teams chat and channel messages, and endpoint devices. Endpoint DLP requires the Microsoft Purview client to be onboarded to devices, check Settings > Device onboarding for status. A device that shows as "Not onboarded" will never generate endpoint DLP events regardless of your policy settings.
# Check DLP policy status via PowerShell
Connect-IPPSSession
Get-DlpCompliancePolicy | Select-Object Name, Mode, Workload, EnabledIf Mode shows TestWithNotifications or TestWithoutNotifications, the policy is still in simulation. Use Set-DlpCompliancePolicy -Identity "Policy Name" -Mode Enable to enforce it immediately.
Microsoft Purview Compliance Manager gives you a real-time compliance score and maps your controls to regulatory frameworks like GDPR, HIPAA, ISO 27001, NIST, and dozens more. Getting your first assessment running is straightforward once you know where everything lives.
Navigate to purview.microsoft.com > Compliance Manager. Your compliance score loads on the overview page, Microsoft pre-populates it with the Microsoft Data Protection Baseline assessment automatically. This score reflects your current tenant configuration against Microsoft's baseline controls, and it updates in near-real-time as you change settings across Microsoft 365.
To add a regulation-specific assessment, click Assessments > Add assessment. Choose your regulation (e.g., GDPR, HIPAA/HITECH, SOC 2). Select the product group (Microsoft 365 for cloud workloads). Name the assessment and assign it to a group, groups let you share evidence and controls across multiple assessments.
Once the assessment is created, open it and go to the Controls tab. Each control shows a status: Microsoft-managed controls are handled automatically by Microsoft and are already marked complete. Your job is to address the customer-managed controls, these require action from your side, like enabling MFA, configuring audit logging, or documenting your data processing agreements.
For each customer-managed control, click it, then click Manage improvement actions. Each improvement action has detailed implementation guidance, a testing procedure, and a place to upload evidence documents. Completing these actions directly raises your compliance score.
One thing that trips people up: Compliance Manager assessments don't automatically scan your environment. They surface configuration data from Microsoft Secure Score and other telemetry, but the evidence and documentation for customer-managed controls has to be added manually. Set a recurring calendar reminder to review open improvement actions, leaving them unaddressed causes your score to drift downward as new controls are added to the framework.
Advanced Troubleshooting
Sensitivity Labels Not Applying in Office Apps, Registry and GPO Checks
If sensitivity labels are published but still not showing in Office apps for specific users or machines, start with the registry. On the affected machine, open Registry Editor and navigate to:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Security\LabelsIf this key doesn't exist, the AIP unified labeling client hasn't initialized correctly on this machine. Check whether the user's Office apps are Current Channel or Semi-Annual Channel, Semi-Annual Channel versions lag behind on sensitivity label features by several months. If your organization uses Group Policy to manage Office updates, verify that the GPO setting Target Version isn't pinning Office to an outdated build.
For domain-joined machines, also check whether a GPO under Computer Configuration > Administrative Templates > Microsoft Office 2016 > Security Settings is disabling the use of classification labels. The setting is called Use the Sensitivity feature in Office to apply and view sensitivity labels, it must be set to Enabled or Not Configured.
Data Map Scan Failures, Event Log Analysis
When a Purview Data Map scan fails without a clear error in the portal, the scan runtime logs more detail in Azure Monitor. In the Azure portal, go to your Purview account > Monitoring > Diagnostic settings. Enable ScanStatusLogEvent and send it to a Log Analytics workspace. Then run this Kusto query to see scan errors:
PurviewScanStatusLogs
| where ResultType == "Failed"
| project TimeGenerated, DataSourceName, ScanName, ErrorMessage
| order by TimeGenerated descThe ErrorMessage column will tell you exactly what the scanner hit, authentication failure, network timeout, unsupported file type, or capacity limits.
DLP Policy Conflicts and Precedence Issues
If you have multiple DLP policies that could apply to the same content, Microsoft Purview evaluates them in priority order, lower number means higher priority. Conflicts between policies resolve by applying the most restrictive rule. If a policy is blocking something it shouldn't, check DLP > Policies and look at the priority numbers. You can drag policies to reorder them. Also check whether an overly broad policy higher in the priority list is catching content before a more specific (and permissive) policy lower down gets evaluated.
Insider Risk Management Policies Not Generating Alerts
Microsoft Purview Insider Risk Management requires HR connector data or other signal sources to be configured before the policy generates meaningful alerts. Go to Data connectors in the Purview portal and verify that your HR connector (or Microsoft 365 HR connector) is connected and showing a Healthy status. A connector in Error state means the policy can't correlate departure events, which silences most alert triggers.
If your Data Map provisioning is stuck in a "Creating" state for more than 2 hours, if Compliance Manager is showing an HTTP 500 error on the overview page, or if your DLP policies are configured correctly but audit logs show no events being captured at all, these are backend service issues that no amount of local troubleshooting will fix. Open a support ticket directly at Microsoft Support. When you do, include your Purview account resource ID from the Azure portal, the exact timestamps of failed operations, and any correlation IDs from error messages, these appear in the browser's developer console under the Network tab and cut resolution time dramatically.
Prevention & Best Practices
Most Microsoft Purview setup headaches I've seen aren't random, they follow predictable patterns that good planning eliminates before they happen. Here's what actually helps in production environments.
Design your collection hierarchy before you register anything. The Data Map collection structure is hard to change retroactively once scans are running and catalog items have been catalogued. Spend 30 minutes mapping out your data estate, by business unit, geography, or data classification tier, and build that hierarchy in Purview before you register a single data source. Moving assets between collections after the fact is possible but tedious and causes lineage data to break.
Use label groups and sub-labels strategically. Don't create 40 flat sensitivity labels. Use parent labels (Public, General, Confidential, Highly Confidential) with sub-labels for variations (Confidential – All Employees, Confidential – Finance Only). This keeps the user-facing label menu clean and makes DLP policy conditions easier to write, you can target an entire parent label rather than listing every sub-label individually.
Run DLP policies in simulation mode for at least two weeks before enforcing. This sounds obvious, but I've seen teams skip simulation and immediately block legitimate business workflows, credit card numbers in procurement systems, SSNs in HR forms, because their policy scope was too broad. Use Activity Explorer during the simulation period to identify false positives and refine rule conditions before you start blocking real work.
Set up diagnostic settings on day one. Before you run your first Data Map scan or publish your first DLP policy, enable Azure Monitor diagnostic logs on your Purview account. This gives you a historical record of every scan, every policy match, and every permission failure, information you absolutely need when something breaks three months later and you're trying to figure out when it started.
Assign Purview roles to groups, not individuals. Managing individual user role assignments in a growing organization is unsustainable. Create Entra ID security groups (e.g., "Purview-DLP-Admins", "Purview-DataCurators") and assign roles to those groups. Onboarding a new team member to Purview then requires a single group membership change, not five separate role assignments across five different role groups.
- Enable the Microsoft Data Protection Baseline assessment in Compliance Manager on day one, it gives you an immediate baseline score and surfaces the highest-impact configuration gaps without any manual setup.
- Turn on audit logging in the Purview compliance portal under Audit > Start recording user and admin activity, this is not on by default in all tenants and is required for eDiscovery, Insider Risk, and DLP investigations.
- Configure Information Protection auto-labeling in simulation mode first; review the What-if results for 7 days before turning on enforcement to avoid labeling false positives at scale.
- Review the Data Security Posture Management (DSPM) overview page monthly, it now unifies risk signals across Purview solutions and surfaces sensitive data risks that individual solution dashboards don't highlight on their own.
Frequently Asked Questions
Why are my Microsoft Purview sensitivity labels not showing up in Word or Outlook?
The most common reason is that the label policy hasn't been published to the affected user. Go to Information Protection > Label policies in the Purview portal and confirm the user is within the policy's scope, either directly or via a group. If the policy is published correctly, allow up to 24 hours for the change to sync to the client. You can speed this up by signing the user out of all Office apps and back in, or by running Start-Process "olk:" -ArgumentList "--resetlabelscache" on the machine to force a label cache refresh.
My Microsoft Purview DLP policy is turned on but it's not blocking any files, what am I missing?
Check the policy mode first. Go to Data Loss Prevention > Policies, click your policy, and look for Policy mode, if it says "Test" or "Simulation," the policy is not enforcing. Change it to Turn on right away. Also verify that the workload locations in the policy include the location where the content lives, a policy scoped only to Exchange will never block a file being uploaded to SharePoint. Finally, confirm endpoint devices are onboarded if you're targeting endpoint DLP.
How long does a Microsoft Purview Data Map scan take, and why does mine seem stuck?
Scan duration depends entirely on data volume. A first-time full scan of a large Azure Data Lake with millions of files can take several hours. Incremental scans on subsequent runs are much faster. If a scan shows "In Progress" for more than 6 hours on a moderately sized source with no progress, it's likely stuck due to a transient authentication issue or network timeout. Cancel the scan from Data sources > [your source] > View scan details, verify your scan credentials are still valid, and re-run. Enable Azure Monitor diagnostics to see the specific error causing the stall.
What's the difference between the Microsoft Purview Unified Catalog and the old Azure Purview Data Catalog?
Microsoft rebranded Azure Purview to Microsoft Purview in 2022 and has since been consolidating features. The Unified Catalog is the evolved version of the old Data Catalog, it now includes business glossary, data lineage, health management, and Fabric integration that the original catalog didn't have. If you're migrating from Azure Purview, your existing scanned assets, glossary terms, and collections carry over automatically. The portal URL changed from the old Azure Purview Studio to the current purview.microsoft.com, which is where all governance and compliance features now live together.
Can I use Microsoft Purview DLP to protect data in non-Microsoft apps like Google Drive or Salesforce?
Yes, with the right licensing. Microsoft Purview DLP for non-Microsoft cloud apps works through Microsoft Defender for Cloud Apps integration. You need a Microsoft 365 E5 or Compliance E5 license, and Defender for Cloud Apps must be configured with an API connector to the third-party app. Once connected, you can create DLP policies in Purview that target "Microsoft Defender for Cloud Apps" as a location and select specific apps from the connected app list. The DLP engine applies the same sensitive information types and label conditions as it does for native Microsoft 365 workloads.
What does the Microsoft Purview compliance score in Compliance Manager actually mean, and is 100% achievable?
The compliance score is a point-based metric that reflects how well your tenant configuration aligns with the controls in your active assessments, it's not a pass/fail certification. Microsoft-managed controls (things Microsoft handles on its infrastructure) contribute automatically. Your score rises as you complete customer-managed improvement actions. A score of 100% means you've addressed every improvement action in your active assessments, but it doesn't mean you're certified or audit-ready, that still requires external auditors. In practice, most mature organizations land between 60–85% once they have GDPR, ISO 27001, and their data protection baseline assessments running simultaneously.