Information Protection for Power BI - Getting Sensitivity Labels Right

Here's a scenario I've seen more than once. A payroll report in Power BI is locked down tight. Workspace access is restricted, row-level security is in place, and only HR can see it. Then someone in HR exports the underlying data to Excel to do a quick bit of analysis, saves it to their OneDrive, and emails it to a contractor. All the careful security in Power BI stopped mattering the moment the data left the platform.

That's the gap information protection is meant to close. Power BI security controls who can see content inside Power BI. Information protection, through Microsoft Purview sensitivity labels, is about classifying data and making that classification (and in some cases encryption) follow the data when it leaves.

Microsoft's Power BI implementation planning guidance has a detailed article on information protection. This post covers what I think matters from it, and what we've learned rolling out sensitivity labels with Australian clients.

What sensitivity labels actually do in Power BI

A sensitivity label is a tag like "Public", "General", "Confidential" or "Highly Confidential" that you define once in Microsoft Purview and apply across Microsoft 365, including Power BI. In Power BI, labels can be applied to semantic models, reports, dashboards, dataflows and most Fabric items.

On their own, inside Power BI, labels don't restrict access. That surprises people. A report labelled "Highly Confidential" is visible to anyone with workspace or app access, same as before. What the label does inside Power BI is make the classification visible, so users see a label next to the content name and know to handle it with care.

The protection kicks in when data leaves Power BI. Export a labelled report to Excel, PowerPoint or PDF, and the label goes with the file. If that label has encryption configured in Purview, the exported file is encrypted, and only people with the right permissions can open it, wherever the file ends up. That's the payroll scenario above, fixed.

The features worth knowing about

The guidance covers a lot of ground. These are the capabilities I think most organisations should understand before they start.

Label inheritance from data sources. Power BI can pick up labels from certain data sources, such as Azure SQL Database or Azure Synapse, when those sources have been classified in Purview. The label flows into the semantic model on refresh.

Downstream inheritance. When a semantic model has a label, reports and dashboards built on it can inherit that label automatically. Change the model's label to something more restrictive, and downstream content follows. This is one of the most useful features, because it means you label the model once and the reports pick it up.

Inheritance on creation. When someone creates a new report from a labelled semantic model in Power BI Desktop or the service, the new report gets the label.

Mandatory labelling. You can require users to apply a label before saving or publishing content. More on this below, because it's a double-edged sword.

Default labels. Apply a default label (usually "General" or equivalent) to anything created without one. This at least means nothing is unlabelled.

Export protection. As above, labels and encryption carry into exported files. This works for Excel, PowerPoint and PDF exports, and for "Analyze in Excel" connections.

Data loss prevention policies. Purview DLP policies for Power BI can detect sensitive information types (like Australian tax file numbers or Medicare numbers) in semantic models and raise alerts or policy tips. These run against semantic models in Premium or Fabric capacity.

Defender for Cloud Apps. For organisations with the licensing, session policies can block downloads or exports of labelled content in real time, based on conditions like whether the user is on an unmanaged device.

What we've seen work

Get the label taxonomy agreed first, and keep it short. The worst rollouts I've seen started with a taxonomy of 12 labels and sub-labels designed by a committee. Users don't read label descriptions. They pick whatever gets the dialog box out of the way. Four or five labels, with names people understand without training, work far better. If your organisation already has a classification scheme for documents and email, use it. Don't invent a separate one for Power BI.

For Australian government and agencies aligned to the Protective Security Policy Framework, you'll likely map to OFFICIAL, OFFICIAL: Sensitive and PROTECTED. Private sector organisations have more freedom, and simpler is almost always better.

Label the semantic models first. Because of downstream inheritance, labelling the shared semantic models gets you most of the coverage for a fraction of the effort. Start with your certified and promoted models, then work outwards.

Be careful with mandatory labelling. It sounds like the obvious choice. In practice, if you turn it on before users understand the labels, you get a flood of content labelled "General" because that's the first option. You end up with 100% label coverage and very little accuracy. I'd rather have a default label plus targeted work on sensitive content, then consider mandatory labelling once people are used to the idea.

Test encryption with real workflows before you turn it on broadly. Encrypted exports are great until someone discovers that the finance team's month-end process pulls data into an Excel file that gets opened by a system account or an external auditor. Encryption will break that. Find these processes before your users do. Also check how your organisation handles guest users, since B2B guests need permissions configured in the label to open protected files.

Connect it to your auditing. Labels generate activity events. Combined with tenant-level auditing, you can report on how much content is labelled, which labels are being applied, and how much highly confidential data is being exported. Without this, you've got no idea whether the program is working.

What's still rough

I'd be doing you a disservice if I pretended this was all smooth.

Licensing is confusing. Applying labels in Power BI needs Microsoft 365 E3/E5 or equivalent Purview licensing for the users involved, plus Power BI Pro or PPU. Some features, like auto-labelling and DLP, need higher tiers or Fabric capacity. Get the licensing sorted out early, because it's not unusual to discover halfway through a project that a feature you planned around needs E5.

Coverage isn't universal. Not every export path or item type carries labels the same way, and support has been expanding over time. Check the current documentation for the specific export formats and item types you care about rather than assuming.

Labels in Desktop files need attention. If a .pbix file is saved with an encrypted label, only authorised users can open it in Desktop. That's intended behaviour, but it catches out developers who share .pbix files around or keep them in source control, and it can complicate deployment pipelines.

Auto-labelling for Power BI is still limited compared to documents and email. You'll rely more on inheritance and manual labelling than on Purview automatically detecting sensitive data and applying labels.

Where to start

If you're at the beginning, my suggested order is:

1. Agree a short label taxonomy with your security or compliance team, ideally reusing the one already in place for Microsoft 365.
2. Enable sensitivity labels in the Power BI tenant settings, initially for a pilot security group.
3. Turn on downstream inheritance and set a default label.
4. Label your key shared semantic models manually.
5. Test export protection with the teams who export the most data.
6. Extend to all users, then consider DLP policies and mandatory labelling.
7. Report on label coverage and exports through your audit data.

This is one of those areas where the Microsoft tooling is genuinely good, but the hard part is people and process rather than configuration. It usually works best as a joint effort between the BI team and whoever owns security and compliance.

If you'd like help planning or rolling out information protection for Power BI, our Power BI consultants have done this with organisations across financial services, government and healthcare. And if you're also thinking about how AI tools like Copilot interact with labelled data (they respect labels, which is another good reason to get them right), our Microsoft AI consultants can help you plan both together. For regulated industries, we also work with government clients on these exact problems.

Reference: Power BI implementation planning - Information protection for Power BI - Microsoft Learn