The challenge: Broad access, growing risk
Organizations are racing to democratize data through Power BI, giving more people access to more insights, faster. But as data access expands, so does the risk of oversharing. A single semantic model might feed dozens of reports consumed by hundreds of users across departments, partners, and geographies.
Traditional Power BI security (workspace roles, row-level security, item permissions) governs who can see what. But it doesn't answer a critical question: what happens when sensitive data needs to be restricted based on its classification, not just its location?
This is where Microsoft Purview protection policies come in.
What are protection policies?
Protection policies are a Microsoft Purview information protection capability that lets you control access to Fabric items based on their sensitivity label. When a protection policy is associated with a label (for example, "Highly Confidential"), only the users and groups specified in the policy retain access. Everyone else is blocked automatically, at runtime.
Think of it as classify once, enforce everywhere.
Unlike traditional workspace-level permissions, protection policies follow the data's classification. If an item is labeled "Highly Confidential – Finance," only the finance team retains access, regardless of which workspace the item lives in.
Why semantic models are the key to protecting Power BI
Here's an important architectural insight: protection policies currently support Power BI semantic models, but not reports or dashboards directly.
At first glance, this might seem like a limitation. In practice, it's actually the most effective enforcement point:
- Semantic models are the data layer. Reports are visualization layers that query semantic models. If access to the semantic model is blocked, the report becomes empty—the data simply isn't returned.
- One semantic model, many reports. Protecting at the semantic model level gives you a single control point that secures all downstream reports built on that model.
- Labels inherit downstream. When you apply a label to a semantic model, it propagates to connected reports via downstream inheritance, ensuring classification consistency without manual effort.
The practical takeaway: To protect Power BI reports using protection policies, apply the sensitivity label (with an associated protection policy) to the semantic model or its upstream Fabric items (e.g., a Lakehouse or Warehouse that feeds the model).
Getting started
- Configure protection policies in Purview – Work with your compliance team to define labels with a Protection Policy specifying which users/groups are allowed. For example: "Highly Confidential – Finance" → only members of the Finance Analytics group. To learn more, refer to Create and manage protection policies for Fabric.
- Apply labels to semantic models - Either manually by data owners, or through:
- Default labels — automatically applied when items are created in a workspace
- Mandatory labeling — ensures no item is saved without a label
- Downstream inheritance — label propagates from source to semantic model to reports
- Enforcement is automatic — Once the label is on the semantic model and the policy is active, unauthorized users are blocked from accessing the data. Reports built on that model will not render data for blocked users.
Summary
Protection Policies bring a fundamentally different approach to Power BI security. Instead of managing access workspace-by-workspace or item-by-item, you define what level of data sensitivity requires, what level of access — and the platform enforces it automatically, wherever that data lives.
For Power BI, the semantic model is your strategic enforcement point. Label it, protect it, and every report downstream is secured.
Learn more
Explore the following resources and documentation to learn more:
Microsoft Employee