Picture this: your company's CFO forwards you a frantic email from your external auditor. Someone in the sales department published a Power BI report containing customer PII and revenue projections to a public-facing embedded endpoint. The report has been accessible to unauthenticated users for three weeks. Your GDPR response team is now involved, legal is drafting breach notifications, and you're suddenly the most important person in the building — for all the wrong reasons.
This scenario plays out more often than you'd think, and in almost every case the root cause isn't malice. It's a combination of overly permissive tenant defaults, no sensitivity label enforcement, and governance policies that exist only in a SharePoint document nobody reads. Power BI's administrative controls are powerful enough to prevent exactly this kind of incident, but they require deliberate, layered configuration — not the out-of-the-box defaults Microsoft ships.
By the end of this lesson, you will have the knowledge to design and implement a complete data protection posture in Power BI: locking down tenant settings to match your organizational risk tolerance, deploying Microsoft Purview sensitivity labels that travel with your data, configuring automatic labeling policies, and validating that your controls actually work. This isn't a compliance checkbox exercise — you're building real defense in depth.
What you'll learn:
Before diving in, you should be comfortable with:
You'll need one of these roles: Power BI Service Administrator, Global Administrator, or Compliance Administrator (for the Purview portions). Sensitivity label configuration specifically requires the Information Protection Administrator role in Microsoft Purview.
Before you touch a single setting, you need a mental model of how governance is layered in Power BI. There are three distinct tiers of control, and they work together rather than in isolation.
Tier 1: Tenant Settings live in the Power BI Admin portal and control what capabilities exist at all within your tenant. Think of these as circuit breakers. If a capability is disabled at the tenant level, no workspace-level override and no user preference can turn it back on.
Tier 2: Workspace Settings and Capacity Settings control behavior within specific containers. Workspace admins have significant latitude here — but only within the envelope of what tenant settings permit.
Tier 3: Sensitivity Labels and Information Protection are applied to individual content items (datasets, reports, dashboards, dataflows, Power BI files). These labels travel with the data when it's exported, constraining what can be done with it outside Power BI.
The critical insight is that Tiers 1 and 3 need to be configured together to form a coherent policy. You can enforce sensitivity labels perfectly on every report in your tenant, but if your tenant settings still allow anonymous public embedding, you've left a major gap. Conversely, locking down tenant settings without labeling means your data has no protection at all once it leaves the Power BI boundary through a perfectly-legitimate export.
Let's build from the bottom up.
Navigate to app.powerbi.com, select the gear icon in the top-right corner, and choose "Admin portal." If you don't see this option, you don't have a Power BI admin role — stop here and get that sorted before proceeding.
The Admin portal's "Tenant settings" section is organized into functional groups. We're going to work through the security-relevant groups deliberately. The approach I recommend: start with your most restrictive posture and selectively open capabilities to specific security groups, rather than enabling broadly and trying to restrict after the fact. Retrofitting restrictions causes user friction and generates support tickets. Starting locked down generates questions during rollout that you can answer systematically.
This group contains the settings most directly implicated in data breach scenarios. Work through each of these carefully.
Allow shareable links to grant access to everyone in your organization Set this to "Disabled" unless you have a specific, documented reason to allow it. Org-wide shareable links bypass workspace permissions and allow anyone with the link to view content regardless of their role in a workspace. If you need broad internal sharing, proper workspace membership or app distribution is a better model.
Allow shareable links to grant access to everyone (including external users) This should almost certainly be disabled unless you're in a consumer-facing reporting scenario with explicit sign-off from your security team. This is one of the settings that enables the CFO's nightmare scenario from the introduction.
Export to Excel
Rather than a binary enable/disable, think about this in terms of your data classification strategy. If you have highly sensitive datasets, you might want to restrict Excel export to specific security groups of power users. Create an Azure AD group called something like SG-PowerBI-DataExporters and populate it with users who have legitimate need for raw data export. Then configure this setting to "Specific security groups" and point it at that group.
Here's the general pattern you'll follow repeatedly across these settings:
Setting: Export to Excel
Enabled for: Specific security groups
Applied to:
- SG-PowerBI-DataExporters (enabled)
Excluded from:
- SG-PowerBI-GuestUsers (disabled for this group even if globally enabled)
This group-based targeting is the key to nuanced governance. You're not choosing between "everyone can do this" and "nobody can do this."
Export to CSV, Export to PDF, Export to PowerPoint Apply the same thinking. PDF and PowerPoint are generally lower risk than CSV because they're harder to bulk-process programmatically, but they can still expose sensitive visualized data. Consider whether your sensitivity label policies (which we'll configure shortly) can handle these exports through encryption rather than blocking them outright — that's a more user-friendly approach.
Publish to web This creates a public, unauthenticated iFrame embed. Disable this tenant-wide unless you have a specific public-facing reporting use case. Even then, consider whether embedding with token-based authentication is more appropriate. There is almost no enterprise scenario where "Publish to web" should be enabled for all users.
Setting: Publish to web
Status: Disabled
Allow external data sharing (in-tenant dataset sharing via Direct Lake) Leave disabled unless you've specifically designed cross-organization data sharing workflows. This is a newer capability that deserves its own governance review before enablement.
Create workspaces (new workspace experience)
You have a choice here between allowing all users to create workspaces or restricting it to specific groups. For enterprises with mature governance, restricting workspace creation to a SG-PowerBI-WorkspaceProvisioners group — and then supporting those requests through a lightweight provisioning process — dramatically reduces workspace sprawl and makes your tenant auditable.
Allow guest users to access Power BI Azure B2B guest access is legitimate and useful for partner reporting scenarios. But it should be paired with appropriate workspace configurations and, critically, with sensitivity labels that restrict what guest users can export. Enable this for a specific group if needed; don't enable it tenant-wide.
Allow service principals to use Power BI APIs
Service principals are how your automated pipelines, CI/CD processes, and embedded applications authenticate to Power BI. This should be enabled for a specific security group containing only your registered application service principals — not opened broadly. In Azure AD / Entra ID, create a security group like SG-PowerBI-ServicePrincipals, add your app registrations to it, and reference that group in this setting.
Embed content in apps Required for embedded analytics scenarios. Restrict to the service principal group mentioned above.
This section is where Tier 1 and Tier 3 start to connect.
Apply sensitivity labels from data sources to their data in Power BI Enable this. When a dataset pulls from a SQL database or Azure Synapse table that already has a sensitivity label applied through SQL Information Protection, Power BI will inherit that label automatically. This is label inheritance at the data source level and it's one of the most powerful automatic enforcement mechanisms available.
Restrict content with protected labels from being shared via link with everyone in your organization Enable this. This setting ensures that even if a user tries to share content labeled as "Confidential" or higher via an org-wide link, the system blocks it. Sensitivity labels become a hard enforcement mechanism rather than advisory metadata.
Allow workspace admins to override automatically applied sensitivity labels This is a judgment call. Disabling it ensures that automatic label policies (which we'll configure in Purview) can't be overridden by workspace admins who might not understand why the label was applied. Enabling it allows for legitimate edge cases where the automatic labeling is wrong. I'd recommend disabling it initially and enabling it selectively after your automatic labeling is tuned, or restricting override ability to a specific admin group.
Sensitivity labels are the mechanism through which data classification becomes enforceable policy. When you apply a "Highly Confidential" label to a Power BI dataset, that label isn't just metadata — it can trigger encryption, access restrictions, watermarking, and audit events that follow the data across export formats.
Before you touch any label configuration, verify:
Warning: Sensitivity labels in Power BI require that users have an appropriate Azure Information Protection license. If you enable mandatory labeling before confirming this, users without licenses will be unable to save Power BI Desktop files. Confirm licensing across your user base before enforcing mandatory labeling.
The most common mistake in sensitivity label implementations is building the labels first and designing the taxonomy later. Resist the urge to jump into the Purview portal and start creating labels immediately.
Sit down with your data stewards and legal/compliance team and map out your actual data classification categories. A realistic enterprise taxonomy might look like this:
| Label | Scope | Typical Content |
|---|---|---|
| Public | External sharing allowed | Marketing reports, public financial summaries |
| Internal | Org-only access | Operational metrics, non-sensitive business data |
| Confidential | Restricted internal | Customer data, HR metrics, financial projections |
| Highly Confidential | Need-to-know + encryption | PII, payment data, M&A analysis, board materials |
Note that this is four levels, not fifteen. More labels means more user confusion and worse compliance. Each label in your taxonomy needs a clear, answerable question: "How do I know if my report belongs in this category?" If the answer requires a lawyer to explain, your users won't apply the label correctly.
Navigate to compliance.microsoft.com. In the left navigation, expand "Information protection" and select "Labels."
Creating the Confidential label (we'll use this as our worked example):
Select "Create a label." On the first screen:
ConfidentialConfidentialUse for reports and datasets containing customer data, internal financial information, or business-sensitive content not intended for external audiences.Data classified as Confidential requires authentication to access. Export is permitted but content is encrypted when sent outside the organization.On the "Define the scope for this label" screen, ensure "Files and emails" and "Power BI items (preview)" are both selected. The Power BI items scope is what makes the label available in the Power BI service — without it, users will only see the label in Office applications.
On the "Choose protection settings for labeled items" screen, you have the option to configure encryption. For the Confidential label, configure:
Under "Assign permissions," add your internal users:
Add all users and groups in your organization
Permissions: Co-Author
(This allows editing but not permission changes or removal of protection)
For external sharing, add your specific partner domains with Reviewer (read-only) permissions.
On the "Auto-labeling for files and emails" screen — skip this for now. We'll configure automatic labeling policies separately, which gives you more control.
On the "Define protection settings for Power BI items" screen:
This is the tenant-setting reinforcement at the label level. Even if a workspace admin has permission to share externally, content labeled Confidential won't go to external parties not explicitly permitted.
Save the label. Repeat this process for your other taxonomy levels, adjusting encryption and sharing settings proportionally.
Labels exist in Purview but aren't visible to users until you publish them via a label policy. Navigate to "Information protection" > "Label policies" > "Publish label."
Select the labels you want to include in this policy. For your initial rollout, include all four levels of your taxonomy.
On the "Assign admin units" screen, leave at full directory unless you're running a phased rollout by administrative unit.
On the "Publish to users and groups" screen, you have a decision to make about rollout strategy. For a first deployment, I recommend targeting a pilot group first:
Publish to:
- SG-PowerBI-GovernancePilot (your pilot users)
Exclude:
- (none for now)
After validating the pilot experience, you'll update this policy to include all users.
On the "Policy settings" screen, this is where mandatory labeling lives:
Require users to apply a label to their Power BI content Set this to On after your pilot validates the label experience. During pilot, leave it Off so users can explore without being blocked.
Provide users with a link to a custom help page Point this at your internal governance documentation. Something like your SharePoint intranet page with labeling guidance. Users who don't know what label to apply will click this link — make sure it's genuinely helpful.
Name your policy PowerBI-Sensitivity-Labels-v1 and publish it. Allow 24-48 hours for the policy to propagate to all users.
Manual labeling relies on users making correct decisions consistently. It doesn't scale, and it introduces human error. Automatic labeling policies in Purview scan content and apply labels based on detected sensitive information types — credit card numbers, Social Security numbers, health identifiers, and hundreds of other patterns.
For Power BI specifically, automatic labeling works on datasets when they're published or refreshed. Navigate to "Information protection" > "Auto-labeling" > "Create auto-labeling policy."
Choose the information to apply this label to: Select "Custom" to define your own rules rather than using a template. Financial regulations templates exist but are often broader than you need.
Choose a label to auto-apply:
Select Highly Confidential. Automatic labeling should target your highest sensitivity tier because the cost of a missed label on highly sensitive content is higher than the cost of occasionally over-labeling.
Set up rules for content in Exchange, SharePoint, OneDrive, and Power BI datasets:
For Power BI datasets, add a new rule. Name it PII-Detection-Rule. Under "Content contains," add these sensitive information types:
Sensitive Information Types:
- Credit Card Number (High confidence)
- U.S. Social Security Number (SSN) (High confidence)
- U.S. / U.K. Passport Number (High confidence)
- EU Debit Card Number (High confidence)
- International Banking Account Number (IBAN) (Medium confidence)
Instance count: 1 to Any
Starting with a count of 1 means a single detected instance triggers the label. This is conservative and will generate some false positives initially. You can tune the minimum instance count upward (say, 5 or 10) once you understand your data landscape, but start strict.
Tip: Power BI automatic labeling scans the data in your datasets, not just the report visuals. This means it will catch PII in underlying data columns even if those columns aren't displayed in any published report. This is the behavior you want — a column containing SSNs should trigger Highly Confidential regardless of whether it's visualized.
Simulation mode first: Set the policy to "Simulation" mode before activating it. Purview will show you which datasets would be labeled without actually applying anything. Run the simulation for at least a week and review the results. You'll almost certainly find unexpected content that helps you tune the policy.
After reviewing simulation results and adjusting confidence thresholds and instance counts as needed, activate the policy. The label will be applied automatically on the next dataset refresh cycle.
One of the most powerful — and least understood — features of sensitivity labels in Power BI is downstream inheritance. When a dataset is labeled, reports built on that dataset should inherit the label. When data is exported, the label should follow it into the exported file.
Navigate back to the Power BI Admin portal and confirm "Apply sensitivity labels from data sources to their data in Power BI" is enabled (we set this earlier). This handles the data source → dataset direction.
For dataset → report inheritance, this happens automatically when a report is created from a labeled dataset. The report will adopt the highest sensitivity label of its underlying datasets. This means:
You can verify this behavior in any workspace: open a dataset's settings, confirm its label, then open a report built from that dataset and check its label. They should match (or the report should have the higher of the two labels if it pulls from multiple datasets).
When a user exports a Confidential-labeled report to PDF, the resulting PDF file is encrypted using Azure Information Protection. The user opening the PDF needs appropriate permissions (granted through the label policy) to view it. Someone who receives the file but isn't in your organization, or isn't assigned permissions in the label policy, will see a protected file they cannot open.
This is the key security boundary: your data protection travels outside the Power BI environment. Even if someone exports data, the exported artifact is protected.
Warning: PDF and PowerPoint exports honor label encryption, but CSV and Excel exports have more nuanced behavior depending on your label configuration. Test your specific export paths with your Confidential and Highly Confidential labels before declaring compliance. Some export types may strip the label in certain configurations — verify, don't assume.
External B2B guests represent a distinct governance challenge. They need to see some Power BI content to do their jobs (auditors reviewing dashboards, partner companies consuming operational reports), but they should never see more than is necessary.
In the Admin portal's Tenant settings, under "Export and sharing settings":
Allow specific users to turn on external data sharing Disable this globally. External data sharing (which allows external users to build their own reports on your shared datasets) should be an explicitly approved use case, not a default.
Guest users can access Power BI content
Enable this, but scope it to a specific security group: SG-PowerBI-ExternalCollaborationApprovers. The pattern here is that workspace admins in this group can add guests; workspace admins not in this group cannot.
Users can invite guest users to collaborate through item sharing and permissions
This is more granular sharing. Disable it broadly and enable for your SG-PowerBI-ExternalCollaborationApprovers group.
In Azure AD, ensure your guest users are members of appropriate groups that your label policies reference. If your Confidential label says "Reviewer permissions for external partners from contoso.com," make sure your Azure B2B guest users from contoso.com are invited under that domain — Purview uses the UPN domain to determine which permission tier applies.
Configuration without validation is just optimism. Here's how to verify your tenant settings and label policies are actually working.
The Power BI Activity Log records every significant action in your tenant: who viewed what, who exported what, who changed permissions, and when sensitivity labels were applied or changed. Access it through the Power BI REST API or through the Admin portal's "Activity log" export.
For compliance purposes, you want to monitor these activity events specifically:
ExportArtifact — Someone exported content
SensitivityLabelApplied — A label was applied (manually or automatically)
SensitivityLabelChanged — A label was changed (potential downgrade incident)
SensitivityLabelRemoved — A label was removed (high-priority alert)
ShareReport — Content was shared
PublishToWebReport — Publish to web used (should be zero if you disabled it)
CreateOrganizationalApp — A Power BI App was published
AddGroupMembers — Workspace membership changed
You can pull this data via PowerShell using the Power BI Management module:
Connect-PowerBIServiceAccount
# Get activity events for the past 24 hours
$startTime = (Get-Date).AddDays(-1).ToString("yyyy-MM-ddTHH:mm:ss")
$endTime = (Get-Date).ToString("yyyy-MM-ddTHH:mm:ss")
$activityEvents = Get-PowerBIActivityEvent `
-StartDateTime $startTime `
-EndDateTime $endTime `
-ActivityType "SensitivityLabelChanged" | ConvertFrom-Json
# Find any label downgrades (e.g., from Highly Confidential to Internal)
$downgrades = $activityEvents | Where-Object {
$_.SensitivityLabelEventData.SensitivityLabelId -ne $_.SensitivityLabelEventData.OldSensitivityLabelId
}
$downgrades | Select-Object CreationTime, UserId, ArtifactName,
@{N="OldLabel"; E={$_.SensitivityLabelEventData.OldSensitivityLabelId}},
@{N="NewLabel"; E={$_.SensitivityLabelEventData.SensitivityLabelId}} |
Format-Table -AutoSize
Run this script daily as part of a scheduled compliance check. Any label removal or downgrade on Confidential or Highly Confidential content should generate an alert.
Create a test dataset that contains a column of simulated sensitive data — use obviously fake SSN-format values like 999-00-0001 through 999-00-0010 (the 999 prefix ensures these won't be mistaken for real SSNs). Publish this dataset to a test workspace.
Within 24 hours (or after the next scheduled dataset refresh), check whether the automatic labeling policy applied your Highly Confidential label. Navigate to the dataset in the workspace, select the three-dot menu, and look at "Sensitivity label" in the dataset settings.
If the label wasn't applied, check:
In compliance.microsoft.com, navigate to "Audit" > "Audit search." Run a search for Power BI activities over the past 7 days. You're looking for a healthy volume of SensitivityLabelApplied events, which confirms labels are flowing through your environment.
Also run a search for SensitivityLabelRemoved. Any results here warrant individual review — someone consciously removed a protection label, and you should understand why.
This exercise will take you approximately 90 minutes and is designed to validate that your entire governance stack is working correctly together. You need an environment where you have Power BI admin rights and Purview Information Protection admin rights.
Phase 1: Baseline Configuration Check (20 minutes)
Phase 2: Create and Validate a Sensitivity Label (30 minutes)
Exercise-Confidential with the following configuration:Exercise-Policy that publishes Exercise-Confidential to your own account only (not tenant-wide).Exercise-Confidential appears as an option and apply it.Exercise_Labeled_Report.pbix.Phase 3: Test Label Inheritance and Export Behavior (20 minutes)
Exercise_Labeled_Report.pbix to a test workspace in Power BI Service.Exercise-Confidential.Phase 4: Activity Log Validation (20 minutes)
ActivityType to ExportArtifact.ActivityType to SensitivityLabelApplied and rerun. Find the event corresponding to when you applied the label in Power BI Desktop.Expected outcomes: You should see the label on the published report, export behavior consistent with your label policy, and both events in the activity log. If any of these don't appear as expected, use the troubleshooting section below.
"Labels aren't appearing for users in Power BI Desktop or Service"
The most common cause is that the label policy hasn't propagated yet — allow 48 hours after creation. The second most common cause is that the Power BI items scope wasn't selected when creating the label. Navigate back to the label definition in Purview and confirm the scope includes "Power BI items (preview)." The third cause is licensing — users need appropriate AIP licensing for labels to appear.
"Automatic labeling ran in simulation but isn't applying labels after activation"
Check whether the auto-labeling policy shows as "Active" in Purview (not "Simulation" or "Turning on"). Also confirm that your datasets are being refreshed — automatic labeling in Power BI triggers on dataset refresh, not on a continuous scan. A dataset that hasn't refreshed since the policy was activated won't be labeled yet.
"Users are bypassing sensitivity labels by downloading the .pbix file and re-publishing without a label"
This is a real gap if mandatory labeling isn't enforced in your label policy. Enable "Require users to apply a label to their Power BI content" in your label policy. Additionally, review your tenant settings for who can download .pbix files — this is controlled by the "Allow users to download reports" tenant setting, which you can scope to a specific group.
"A label was applied automatically but it's the wrong label"
Your sensitive information type rules are matching content they shouldn't. In Purview, open the auto-labeling policy and review the simulation results — they'll show which information types matched in which dataset. Increase the minimum instance count for the triggering rule (from 1 to 5 or 10), or increase the confidence threshold from Medium to High. After adjusting, re-run the simulation before reactivating.
"Tenant settings show as configured but users can still share externally"
Check whether the user is a Power BI admin. Power BI administrators bypass most tenant setting restrictions by design. If admins are doing things that regular users shouldn't do, that's a permissions/training issue, not a misconfigured setting. Also check whether the user's security group membership is correct — group membership changes can take up to an hour to propagate in Azure AD.
"The label is applied to the dataset but reports on that dataset don't show the label"
Report-level label inheritance requires that the report was published or last saved after the dataset's label was applied. Open the report in Power BI Desktop, let it connect to the published dataset, then republish — this should sync the label. If you've disabled workspace admin overrides, also confirm that no manual override was applied at the report level that conflicts with inheritance.
"Audit logs show SensitivityLabelRemoved events but I can't tell who did it"
The UserId field in the activity log will contain the user's UPN if the action was manual, or a system identifier if the action was part of an automated process (like a pipeline). If the UserId is a service principal ID rather than a human UPN, check your service principal group in the Developer settings — a pipeline running under a service principal with broad permissions can remove labels programmatically unless you've explicitly blocked it.
You've built a layered data protection strategy that covers the three tiers we identified at the start: tenant-level capability controls, information protection labels with appropriate encryption and sharing restrictions, and automatic labeling that removes human error from classification decisions. The audit trail you've set up means you have evidence of your controls working — which is exactly what external auditors and compliance assessments require.
The CFO's nightmare scenario from the introduction is now preventable by multiple independent controls: Publish to web is disabled at the tenant level (circuit breaker), any customer data would be automatically labeled Confidential or Highly Confidential (labeling layer), and that label would prevent the content from being shared via org-wide link (label enforcement). Three separate mechanisms would have to fail simultaneously to reproduce the breach.
Where to go from here:
Conditional Access Policies for Power BI — Azure AD Conditional Access can require compliant devices or MFA specifically for Power BI access, adding an authentication-layer control to complement your data-layer controls. This is especially important for guest users.
Power BI Deployment Pipelines with Governance Gates — Integrate label validation into your CI/CD pipeline so that content can't be promoted to production unless it has a required sensitivity label. This requires the Power BI REST API and some scripting, but it closes the gap between development and production environments.
Microsoft Defender for Cloud Apps Integration — Defender for Cloud Apps can monitor Power BI sessions in real time and alert on anomalous behavior (unusual export volumes, access from unexpected locations). It integrates with your sensitivity labels to create alert policies tied to specific label tiers.
Data Loss Prevention (DLP) Policies for Power BI — Microsoft Purview DLP policies can now target Power BI datasets directly, generating alerts or blocking actions when sensitive content is detected. This is distinct from sensitivity labels and adds another detection layer for content that hasn't been labeled yet.
The work you've done in this lesson is foundational. Every advanced governance capability in the Power BI and Microsoft Purview ecosystem builds on tenant settings and sensitivity labels being correctly configured. With this foundation solid, you're ready to build the more sophisticated controls on top of it.