Securing Power BI: Sensitivity Labels, Purview and Who Can See What

Scenario: A Cross-Border Finance & HR Dataset That Won’t Sit Still

You manage a Power BI tenant for a mid-sized group with:

• Finance data from an on-premises SQL Server in the Netherlands
• HR data in a SaaS HR system hosted in an EU region
• A standardised group model in Fabric/Power BI used by:
  • Dutch finance and HR
  • A small analytics team in another EU country

The security pain points:

• HR wants strict control over who sees employee-level data in reports.
• Legal wants clarity on where sensitive data is stored and processed.
• IT wants a single place to see lineage and classification across SQL, Fabric and Power BI.
• You already have Microsoft Purview and Microsoft Information Protection (MIP) in place for documents and email.

We’ll tighten this environment around three pillars:

1. Sensitivity labels in Power BI (and how they behave in the service and desktop)
2. Purview integration for lineage, classification and scanning
3. Access paths: who can see what, via which entry point, and how that interacts with labels

Sensitivity Labels in Power BI: What They Actually Do

Power BI uses Microsoft Information Protection sensitivity labels. These are defined in the Microsoft Purview compliance portal (formerly Microsoft 365 compliance center) and then applied in Power BI Desktop and the service.

Where labels can be applied

As of late 2026, you can apply sensitivity labels to:

• Power BI datasets
• Reports
• Dashboards
• Paginated reports
• Dataflows (Power BI / Fabric)

In Power BI Desktop you can set the label at the file level; when you publish, the label flows to the corresponding report and dataset in the service.

What labels control (and what they don’t)

Key behaviours you should rely on:

• Visibility and inheritance
  • A label on a dataset does not automatically enforce row-level security. It classifies the object and can drive protection and policy.
  • A report or dashboard can inherit the label from its dataset if you haven’t set one explicitly (subject to the tenant setting that controls inheritance).
• Export and sharing controls (depending on label configuration and licence)
  • Labels can enforce MIP restrictions like:
    • Blocking export to Excel or .csv for users without rights
    • Applying encryption and usage rights to exported files
    • Controlling copy/paste and printing
  • Power BI respects label policies when users:
    • Export data (summarised or underlying)
    • Download .pbix files (where allowed)
    • Use Analyze in Excel or connected tools
• Cross-product consistency
  • The same label taxonomy is used in Office apps, SharePoint, OneDrive and Power BI.
  • A report exported to PowerPoint or PDF keeps its label and associated protection where supported.

What labels do not do by themselves:

• They do not replace workspace roles or app permissions.
• They do not enforce RLS or Object-level security (OLS).
• They do not change where the data is physically stored (region / sovereignty).

Labels are classification and policy hooks. Access is still controlled by roles, RLS/OLS and tenant settings.

Designing a Label Strategy for Power BI (Not Just for Office)

Most tenants start with labels designed for documents: Public, Internal, Confidential, Highly Confidential. For Power BI, that’s usually too coarse.

For our finance + HR scenario, a workable pattern is:

• Internal – Standard: Non-personal operational reporting
• Confidential – Financial: Detailed P&L, balance sheet, cash flow
• Confidential – HR: Employee-level HR data
• Restricted – HR Identifiable: HR data with identifiers that should never leave HR and Legal

Practical design tips

1. Separate HR and Finance sensitivity
   • HR labels should be stricter on export and external sharing than pure finance labels.
2. Align with RLS segments
   • If you already segment data by country or business unit with RLS, consider labels that reflect the highest sensitivity in each segment.
3. Decide where you enforce protection
   • For Power BI, the most impactful controls are:
     • Export restrictions
     • Download .pbix restrictions
     • External sharing restrictions (B2B)

You configure these behaviours in the label policy in the compliance portal, not in Power BI directly. Power BI then enforces them when users interact with labelled artefacts.

Applying Labels in Power BI Desktop and Service

Desktop: Make the model carry the classification

For our shared finance + HR model:

1. Open the .pbix in Power BI Desktop.
2. On the Home ribbon, use Sensitivity (or the Information Protection button) to select Confidential – HR for the file.
3. Save and publish to the Finance & HR workspace.

Result:

• The report and dataset in the service inherit Confidential – HR (assuming label inheritance is enabled in the tenant).
• Any export from this report respects the HR label’s restrictions.

Service: Override where needed

In the workspace, you might create:

• A finance-only report filtered or modelled to exclude HR tables.
• An HR-only report with RLS restricting to HR users.

For the finance-only report:

1. Open the report in the service.
2. Use Sensitivity in the report toolbar.
3. Set the label to Confidential – Financial.

Now you have:

• Dataset: Confidential – HR (because it contains HR tables)
• Finance report: Confidential – Financial
• HR report: Restricted – HR Identifiable

Each report’s export behaviour follows its own label, even though they share the same dataset.

RLS, OLS and Labels: Who Sees What Inside the Same Dataset

Sensitivity labels are about classification and policy; RLS/OLS are about data slices. You need both.

For the shared dataset:

• RLS to segment by domain:
  • HR role: sees HR tables and employee-level measures
  • Finance role: sees financial tables, no HR
• OLS to hide HR tables from non-HR users entirely

Example: RLS role definitions in the model using Power BI Desktop model view.

-- Example of a simple RLS role filter expression (in Power BI Desktop model view)

-- HR role: can see all employees
[EmployeeAccess] = TRUE()

-- Finance role: cannot see HR data
[EmployeeAccess] = FALSE()

In practice you’d implement [EmployeeAccess] as a Boolean column or measure based on user identity and business rules. OLS is configured separately (for example, using Tabular Editor or the model view in Power BI) to hide HR tables from the Finance role completely.

How this interacts with labels:

• The dataset label reflects the highest sensitivity of any data in the model.
• RLS/OLS restrict what each user can see.
• Export restrictions from the label are applied after RLS/OLS — users can only export what they can see.

For sovereignty discussions, you can now say:

• Sensitive HR data is in a labelled dataset.
• Only HR users can see it via RLS/OLS.
• Exports are restricted by the HR label.

Purview + Power BI: Lineage, Scanning and Sovereignty Questions

Microsoft Purview gives you:

• Data estate scanning (SQL, storage, Fabric, etc.)
• Classification and labelling integration
• Lineage across sources, dataflows, datasets and reports

For our scenario, the governance team wants to answer:

• Where does HR data originate (which systems, which regions)?
• Through which transformations (dataflows, Fabric pipelines) does it reach Power BI?
• Which reports and workspaces consume it?

Enabling Purview scanning for Power BI

At a high level, you:

1. Create or use an existing Microsoft Purview account.
2. Register your Power BI tenant as a data source.
3. Configure scans for Power BI artefacts:
   • Workspaces
   • Datasets
   • Reports
   • Dataflows

Once scans run, Purview can show lineage like:

• On-prem SQL (Netherlands) → Gateway → Dataflow → Dataset → HR report
• SaaS HR system (EU region) → Dataflow → Dataset → HR report

Sovereignty: Region and residency visibility

Purview itself doesn’t move data, but it helps you see:

• Source system locations (e.g., SQL in NL, HR SaaS in EU)
• Fabric / Power BI capacity regions
• Downstream usage: which workspaces and reports use a given dataset

For sovereignty debates, this matters because:

• You can demonstrate that sensitive HR data is only sourced from EU-hosted systems.
• You can check that no dataset using HR tables is deployed to a non-EU capacity.

If you use Power BI Premium or Fabric capacities, capacity region choice is critical. Purview lineage plus capacity metadata gives you a defensible story for where data is processed.

Who Can See What: Access Paths You Need to Audit

With labels and Purview in place, you still need to control how people reach the data.

For the Finance & HR workspace, enumerate access paths:

1. Workspace roles
   • Admin, Member, Contributor, Viewer
   • Viewer is read-only but still subject to labels and RLS.
2. App distribution
   • The Finance & HR app may be shared with:
     • Finance group
     • HR group
     • Executive group
3. Direct report links
   • Shared links to specific reports with build or view permissions.
4. External sharing
   • Azure AD B2B guests accessing the app or workspace.
5. Tools connecting to the dataset
   • Analyze in Excel
   • Power BI Desktop live connection
   • Other tools via XMLA (Premium)

Practical governance steps

For each dataset:

• List all consumers
  • Reports, dashboards, apps and external tools.
• Check effective permissions
  • Who has build rights on the dataset?
  • Who can reshare the app or report?
• Align labels with access
  • If a dataset is Restricted – HR Identifiable, ensure:
    • Only HR and Legal groups have Viewer or higher.
    • No generic “All Employees” group has access to the workspace or app.

Power BI’s View as role feature lets you validate RLS behaviour; Purview gives you lineage; labels enforce export and classification. Together they give you a credible answer to “who can see what”.

Tenant Settings and Default Behaviours You Should Know

A few tenant-level settings affect how well your sensitivity and Purview strategy works.

Key ones to review:

• Information protection in Power BI admin portal
  • Enable sensitivity labels.
  • Allow label inheritance from datasets to reports and dashboards.
• Export and sharing controls
  • Restrict “Export data” where needed.
  • Control “Download .pbix” for non-owners.
  • Configure external sharing defaults.
• Capacity and region choices
  • Ensure HR-heavy workspaces are on EU capacities if sovereignty is a requirement.

These settings don’t override label policies, but they can narrow or widen what users are allowed to do even before labels apply.

One Concrete Takeaway: Start With a Single High-Risk Dataset

If this feels like a lot, don’t try to retrofit the whole tenant in one go. Pick one dataset where sovereignty and sensitivity are non-negotiable — usually HR or detailed payroll.

For that dataset:

1. Apply the right sensitivity label to the dataset and reports.
2. Implement RLS/OLS so only the intended groups can see sensitive tables.
3. Scan with Purview and review lineage and consumers.
4. Lock down exports and .pbix downloads using label policies and tenant settings.

Once you can clearly explain who can see what, through which path, and in which region for that dataset, you have a pattern you can repeat for the rest of your Power BI estate.