Learn › Power BI & Fabric › 3 · Governance & security

Sensitivity labels and DLP in Power BI

Sensitivity labels bring Purview's classification and protection into Power BI, so a 'Confidential' semantic model stays Confidential when someone exports it to Excel. Understand label inheritance, export enforcement, and the DLP policies that scan Power BI content.

What labels do in Power BI

Sensitivity labels are defined centrally in Microsoft Purview (the same labels used across Office and email) and can be applied to Power BI semantic models, reports, dashboards, dataflows and workspaces. A label carries two things: a classification (a visible marking) and optionally protection (encryption + usage rights that travel with the data). Turning this on is a tenant setting ('Information protection').

Inheritance — the point of labels

Labels are only useful if they follow the data:

  • Downstream inheritance in the service — a label on a semantic model can flow to reports/dashboards built on it, so classification propagates as content is derived.
  • Source inheritance — content can inherit labels from labelled data sources it pulls from (so a report over sensitive data gets marked automatically).
  • Export inheritance and enforcement — this is the critical one: when a user exports to Excel, PowerPoint or PDF, the label (and its encryption) travels onto the exported file. A 'Confidential — encrypted' report exported to Excel produces an encrypted Excel file only the authorised can open. Without labels, that export is a naked copy of your data.

DLP for Power BI

Data loss prevention policies (in Purview) can evaluate Power BI semantic models for sensitive information types or labels and take action — alerting or flagging when, say, a model contains card numbers or is mislabelled. This closes the loop between 'the data exists in Power BI' and the org's broader DLP posture.

Failure modes

  • Labels off. The tenant setting disabled means exports leave with no protection at all — the default leak.
  • No mandatory labelling. Labelling allowed but not required, so most content is unlabelled and inheritance/enforcement never triggers.
  • Export enabled, labels not enforced. 'Export to Excel' on for everyone while protection isn't applied — data walks out unprotected (the RLS/export interaction).
  • Broken inheritance chains. Manual relabelling downgrading a Confidential model to a lower label, silently widening what can leave.
  • Guest access + labels. External users' ability to open labelled/encrypted content depends on cross-tenant protection config — misconfigured, either they can't open legitimate content, or protection doesn't apply.

What to watch (proofs)

  • Labelling coverage: the admin scanner (admin/workspaces/getInfo / admin/info) returns the sensitivity label on each item — the census of labelled vs unlabelled sensitive content.
  • The tenant setting itself: 'Information protection' / 'Allow users to apply sensitivity labels' state, captured in the nightly tenant-settings scan (governance concept) with alerting if it flips off.
  • Export controls in concert: export-data / export-to-Excel tenant settings vs labelling posture — export-on + labels-off is the dangerous combination.
  • Label-change activity: Get-PowerBIActivityEvent records label apply/change events — a downgrade on sensitive content is an audit item.
  • DLP policy matches: Purview DLP alerts for Power BI semantic models — content flagged as holding sensitive info types.

PowerShell for this concept

Discussion

No messages yet — start the thread.

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